Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.automagik.dev/llms.txt

Use this file to discover all available pages before exploring further.

Genie ships software that runs with full host privileges. We treat its supply chain as a security boundary, not a logistics problem. This section documents the trust contract you inherit when you install Genie, the verification machinery you can run yourself, and the runbooks for the moments when something goes wrong.

​
The trust contract

Every released Genie artifact (per-platform binary, signature pack, installer script) is signed via cosign keyless through GitHub Actions OIDC and accompanied by SLSA Level 3 provenance. There is no long-lived private key, no hardware-backed offline ceremony — instead, every release artifact embeds a Sigstore certificate identifying the workflow path, OIDC issuer, and source-uri that produced it. Operators verify that identity, not a fingerprint. The pin is byte-identical across four independent channels, so an attacker would need to compromise all four to forge a release without detection:

install.sh inlined

The bootstrap script that runs curl -fsSL get.automagik.dev/genie | bash carries the expected certificate identity at the top of the file. Read it before piping to bash.

SECURITY.md

The repo-root SECURITY.md lists the same identity verbatim. Cross-checks the script.

.well-known/security.txt

Published at automagik.dev/.well-known/security.txt over HTTPS — independent of the GitHub repo. A third pinning channel.

Pinned GitHub issue

A pinned issue in automagik-dev/genie titled SIGNING_KEY_FINGERPRINT_<YYYYMMDD> carries the same identity. Updated only via the key-rotation runbook.
If you ever see a mismatch across these four channels, do not install. File an issue and we’ll investigate before anyone runs anything.

​
Verifying an install yourself

# Verify the running binary against the pinned cosign identity:
genie sec verify-install

# Output:
# ✅ cosign:  signature matches certificate identity
# ✅ slsa:    Level 3 provenance attestation valid
# ✅ source:  binary built from automagik-dev/genie@<commit-sha>
The verifier runs offline — no calls to Sigstore’s transparency log unless you pass --online for an extra check. Mismatch produces a structured exit code (2 = signature-invalid, 3 = identity-mismatch, 4 = provenance-invalid, 5 = no signature material). For mutating subcommands (genie sec remediate --apply), Genie refuses to run on an unverified binary. Override only via the documented --unsafe-unverified <INCIDENT_ID> ack contract; every override is recorded in ~/.genie/audit/sec-scan/<scan_id>.jsonl for forensic review.

​
What lives in this section

Distribution Sovereignty

Why Genie ships through its own CDN with cosign + SLSA verification instead of relying on npmjs.com. The threat model + the verification flow.

Verifying Installs

Step-by-step walkthrough of genie sec verify-install, what each verification stage proves, and how to manually cross-check the four pinning channels.

Key Rotation

When and how Namastex rotates the cosign certificate identity — the runbook operators follow if our signing surface changes.

CanisterWorm Incident Response

Public 2026-04-23 runbook for the npm supply-chain compromise that motivated much of the work documented here.

​
Reporting a vulnerability

Email security@namastex.io with a clear reproduction. We commit to:
  • Acknowledge within 24 hours.
  • Confirm or reject within 7 days.
  • Coordinate disclosure on a 90-day timeline by default. Earlier if exploitation is observed.
Do not file public GitHub issues for security reports; we’ll open the public tracking issue together once mitigation is in flight.