Supply chain trust

Every @mnemom/* npm package is published with SLSA build provenance — a cryptographically signed attestation that binds each published tarball to the exact GitHub Actions workflow run that built it. This guarantees the package you install was built from the source code we published, on infrastructure we control, without a developer’s laptop or long-lived credential in the chain.

What provenance means

When you install a recent version of any @mnemom/* package, 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.

No long-lived npm tokens are used. All publishes authenticate via GitHub OIDC to npm’s Trusted Publisher system.

Runtime supply-chain detection with AEGIS

SLSA provenance verifies the package at build time. The May 2026 Mini Shai-Hulud worm demonstrated that valid SLSA Build Level 3 attestations can be produced for malicious packages when the attacker controls the build pipeline. The cryptographic claim — “this package was built by that build pipeline” — is true; what the claim does not protect against is a compromised pipeline producing a signed worm. Runtime detection is the complementary layer. AEGIS’s substrate fingerprint is the cross-tenant runtime signal. Every evaluation, integrity checkpoint, and arena attempt across every Mnemom customer is stamped with a substrate_id identifying the AI substrate the agent ran on. The base form is <provider>:<model>; when the customer sets the X-Mnemom-Sdk-Version and X-Mnemom-Lockfile-Hash headers, the trigger composes the four-component identifier <provider>:<model>:<sdk@ver>:<lockfile-hash> for deployed-dependency-graph attribution. The L1 cross-tenant aggregator rolls behavioral signal per substrate axis-bucket. Behavioral deviation that appears at every customer running on the same substrate simultaneously is the signature SLSA cannot produce — because the attacker controls the build pipeline, not every customer’s traffic. Customer action items, in order of effort:

Keep verifying SLSA provenance. This guide’s existing content remains the canonical package-layer step. SLSA + Sigstore + the Mnemom Trusted Publisher path is the build-layer foundation.
Read AEGIS L4 + L5 surfaces. The threat thermometer and the IoCs + advisories surfaces publish what AEGIS is detecting in the network — including any substrate-attributed behavioral deviations. Both surfaces are honest about state per the calm-at-GA contract: if the network is calm, the page shows calm.
Opt in to elevated supply-chain attribution. Set the X-Mnemom-Lockfile-Hash header (SHA-256 digest of your resolved manifest) on outbound gateway requests for deployed-dependency-graph attribution at AEGIS’s L0 axis. The companion X-Mnemom-Sdk-Version header tightens SDK attribution when the User-Agent dispatch fallback isn’t enough. See the lockfile-hash opt-in guide for the runnable how-to.

Verifying a package

Quick check with npm

# Install, then verify signatures and attestations for your dependency tree:
npm install @mnemom/agent-integrity-protocol
npm audit signatures

Expected output:

audited 1 package in 0s

1 package has a verified registry signature
1 package has a verified attestation

If any @mnemom/* package in your tree reports missing attestations or unverified, treat it as a supply-chain incident and contact [email protected] before using the installed code.

Inspecting provenance directly

npm view @mnemom/agent-integrity-protocol dist.attestations

You should see an entry like:

{
  url: 'https://registry.npmjs.org/-/npm/v1/attestations/@mnemom%[email protected]',
  provenance: { predicateType: 'https://slsa.dev/provenance/v1' }
}

SBOMs

Every release ships a CycloneDX software bill of materials (SBOM). You can find it in two places:

GitHub Release assets — for packages published via GitHub Releases (e.g., @mnemom/types), the SBOM is attached to the release itself. Example: mnemom/mnemom-types releases.
Workflow run artifacts — every publish workflow run uploads sbom.cdx.json as an artifact, retained for 90 days.

SBOMs are CycloneDX JSON format and can be consumed by any standard SBOM scanner (Grype, Trivy, Dependency-Track, etc.).

Packages covered

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

Package	Repo
`@mnemom/agent-alignment-protocol`	mnemom/aap
`@mnemom/agent-integrity-protocol`	mnemom/aip
`@mnemom/aip-otel-exporter`	mnemom/aip-otel-exporter
`@mnemom/policy-engine`	mnemom/mnemom-platform
`@mnemom/mnemom` (CLI)	mnemom/mnemom-platform
`@mnemom/types`	mnemom/mnemom-types

All publishes use the same canonical workflow, maintained in mnemom/.github, which gives us a single source of truth for the publish recipe and makes drift between repos architecturally impossible.

Reporting concerns

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

​Supply chain trust

​What provenance means

​Runtime supply-chain detection with AEGIS

​Verifying a package

​Quick check with npm

​Inspecting provenance directly

​SBOMs

​Packages covered

​Reporting concerns