feat(mcp): Ed25519 op-envelope signing for destructive ops (KLA-411)

[jklaassenjc]

Summary

Closes KLA-411. Direct response to the user-feedback ask in KLA-408:

For critical tools or actions, such as deletion in a production environment, it would be useful to request JIT authz to have a cryptographic proof of the operation so that responsibility can be traced.

Phase 1 (#23, v1.16.0) shipped TTY step-up. This slice adds the cryptographic proof half: every successful destructive MCP op emits a signed manifest to ~/.config/jc/mcp-audit-signed.log, verifiable post-hoc with jc audit verify.

How it works

Step	What happens
First destructive op fires	Server lazily generates Ed25519 keypair: priv → keychain at service="jc", account "<profile>:signing_key". Pub → config at profiles.<name>.signing_pubkey.
Each successful destructive op	Chokepoint in addTypedTool builds a manifest `{tool, args_redacted, target, timestamp, nonce, operator_pubkey}`, signs the canonical JSON, appends to ~/.config/jc/mcp-audit-signed.log (one line per op, mode 0600).
Failed op	No manifest — the op didn't happen, the regular audit log records the failure.
Plan mode (no execute=true)	No manifest — non-mutating preview.
Verification	`jc audit verify` reads the log, checks each signature against the configured pubkey, exits 0 / non-zero with the offending manifest's nonce.

Why pure Go, no cgo

The user can pair this with their preferred step-up authenticator (TTY today, Touch ID in KLA-412, out-of-band approval in KLA-413) without platform constraints. Signing just adds a forensic record on top.

Crypto: `crypto/ed25519` + `crypto/rand` from the stdlib. No third-party dependency. Manifest canonicalization uses the encoding/json deterministic key order (alphabetical) so verifiers can reconstruct the signed bytes exactly.

What ships

New files

• `internal/mcp/sign.go` — manifestSigner interface, noopSigner, ed25519Signer, VerifyManifestStream(). Pure Go, mutex-protected lazy key load.
• `internal/mcp/sign_test.go` — 10 unit + 3 integration tests covering signer round-trip, keypair reuse, nonce uniqueness, tamper detection, wrong-pubkey rejection, sensitive-arg redaction, chokepoint correctness on success/failure/plan paths.
• `internal/cmd/audit.go` — `jc audit verify` subcommand.
• `internal/cmd/audit_test.go` — 4 CLI tests.

Modified

• `internal/keychain/keychain.go` — SetSigningKey/GetSigningKey/DeleteSigningKey helpers.
• `internal/config/config.go` — `mcp.sign_destructive_ops` config, getter, `ValidConfigKeys`, profile-level `signing_pubkey` accessors.
• `internal/mcp/server.go` — `Options.SignDestructiveOps` + `SigningProfile` + unexported `signer` test seam, wired into NewServer.
• `internal/mcp/tools.go` — chokepoint emits signed manifest after a successful destructive op.
• `internal/cmd/mcp.go` — `--sign-destructive` flag.
• `docs/AUTH.md` — new "Signed audit log" subsection, updated threat-model table to reflect tamper-evident detection on credential-exfiltration and compromised-agent scenarios.

Demo

# Enable signing
jc config set mcp.sign_destructive_ops true

# Or one-off
jc mcp serve --sign-destructive --transport http

# Run a destructive op (from any MCP client)
# … users_delete with execute: true …

# Verify the chain
$ jc audit verify
OK — verified 1 signed manifest(s) for profile "default".

# After tampering
$ sed -i '' 's/alice/bob/' ~/.config/jc/mcp-audit-signed.log
$ jc audit verify
Verified 0 manifest(s) before failure: signature mismatch on manifest #1 (nonce=…, tool=users_delete)
exit 1

Test plan

• `go build ./...` clean
• `go test ./...` — full suite passing
• 10 sign unit tests — noop dispatch, factory; signer round-trip; keypair reuse across multiple ops; nonce uniqueness; verify happy path; tamper detection; wrong-pubkey rejection; sensitive-arg redaction
• 3 chokepoint integration tests — signs successful destructive ops, skips failed ops, skips plan mode
• 4 audit-verify CLI tests — OK path, tamper detection exits non-zero, no-pubkey error, command registration under root
• Flag-defaults test — `--sign-destructive` defaults to false

Defaults

Off. Backwards-compatible with every existing deployment. Operators opt in via `mcp.sign_destructive_ops: true` or `--sign-destructive`.

Follow-ups (separate tickets)

• KLA-412 — Touch ID step-up authenticator (Phase 2 part 2)
• KLA-413 — Out-of-band approval (Phase 3)

🤖 Generated with Claude Code

---

Note

Medium Risk
Adds cryptographic signing and verification around destructive MCP operations, touching keychain storage, config persistence, and the MCP execution chokepoint; bugs could break auditability or cause unexpected signing failures. Defaults are opt-in and failures don’t block ops, reducing operational risk.

Overview
Adds an opt-in signed audit trail for MCP destructive operations: when enabled via mcp.sign_destructive_ops or jc mcp serve --sign-destructive, each successful execute:true destructive tool call appends a per-profile Ed25519-signed JSON manifest to ~/.config/jc/mcp-audit-signed.log (with redacted args, target, timestamp, and nonce).

Introduces jc audit verify to validate the signed log against the profile’s stored public key (or an override key), and extends config/keychain support to lazily generate/store the signing keypair (private key in OS keychain under "<profile>:signing_key", public key persisted to profiles.<name>.signing_pubkey). Documentation and tests are updated to cover the new signing/verification flow and tamper detection behavior.

^{Reviewed by Cursor Bugbot for commit fdd5d1c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 965a444. Configure here.}