Skip to main content
Our npm packages under the @mnemom/* scope are published from GitHub Actions through npm’s Trusted Publisher system, so no long-lived npm token is involved. Packages built from our public repositories also carry SLSA build provenance: a signed attestation that ties the published tarball to the workflow run, repository and commit that built it.

​
What provenance means

For packages with provenance, the tarball on the npm registry is accompanied by a SLSA provenance attestation (predicate type https://slsa.dev/provenance/v1). The attestation is:
  • Signed via sigstore, using short-lived keys issued only to the specific GitHub Actions workflow run.
  • Bound to the source — records the exact commit SHA, repository, and workflow path used to build the package.
  • Transparent — published to the public sigstore transparency log; anyone can audit the full signing history.

​
Packages without provenance

npm only issues provenance for packages built from a public source repository. Packages built from our private platform repository are published through Trusted Publisher without a provenance attestation: the CLI (@mnemom/mnemom), @mnemom/sdk, @mnemom/policy-engine and @mnemom/team-coherence. Earlier releases of some of these, published while that repository was public, do carry provenance. For these packages, npm audit signatures reports a verified registry signature and may report no attestation; that is expected.

​
Recording what your agents ran on

Provenance covers the packages you install. To record which SDK, and optionally which dependency lockfile, each agent call ran on, use the substrate fingerprint: the gateway stores it on every integrity checkpoint. If you later learn that a dependency was compromised, you can find the checkpoints, and so the agent decisions, that ran on it. See the lockfile-hash opt-in guide to set it up. Mnemom does not analyze fingerprints for compromise; it records them for your audit.

​
Verifying a package

​
Quick check with npm

Expected output:
If any @mnemom/* package not listed under packages without provenance reports missing attestations, or any package reports an invalid signature, treat it as a supply-chain incident and contact security@mnemom.ai before using the installed code.

​
Inspecting provenance directly

You should see an entry like:

​
SBOMs

Each publish generates a CycloneDX software bill of materials (SBOM). For packages released from our public repositories, the SBOM is attached to the GitHub release, for example on mnemom/mnemom-types releases. SBOMs are CycloneDX JSON and work with standard scanners such as Grype, Trivy and Dependency-Track.

​
Packages covered

All packages under the @mnemom/* scope on npm. A non-exhaustive list:

​
Reporting concerns

If you encounter a package that fails verification, or you have questions about the supply-chain posture, email security@mnemom.ai or see our security policy.