security

cachet assumes the author is an untrusted, possibly-hijacked program and the build environment is hostile. Every control flows from that. This is the opposite of GitHub's model, which was built for trusted human authors.

Five leapfrog moves

• TEE-attested builds Checks and builds run in confidential compute: memory is encrypted, the operator can't inspect it, and the workload must present a hardware attestation before cachet releases any secret or signing capability. A poisoned runner can't extract a token it never sees in plaintext memory.
• Keyless signing, cachet-native PKI Short-lived SSH certificates bound to the cachet identity, recorded in cachet's own tamper-evident Merkle log. No long-lived agent signing key. No external Sigstore dependency. cachet is the CA and the forge: every commit, verdict, and merge is signed and logged.
• Tamper-evident decision log Every verdict, score, token mint, and merge is appended to a Merkle transparency log. Cryptographically verifiable after the fact. The auto-merge record is reconstructable from commit to gate verdict to signed land — not "trust us."
• Agents are untrusted by default An agent token is short-TTL, sender-bound, scoped to one org and one operation. No standing privilege. No blast radius beyond what the grant names. The gate is the only path to merge — no side API can bypass it. Anomalous scope or volume trips the circuit breaker.
• Immutable tags Tags are create-only at the server: a force-push or delete-recreate is refused at the git layer. A published tag is frozen — downstream consumers that pin a tag get the same bytes that were reviewed and signed. Not advisory; structural.

Full threat model and control map: docs → SECURITY. Responsible disclosure: security.txt.