How we handle your keys and your code.

Every provider API key you enter in the setup app is written to the macOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly — meaning the key is readable only while the device is unlocked, and it never leaves this Mac.

Only one binary can read those Keychain items: jointchiefs-keygetter, a minimal Swift executable signed with your Apple Developer ID. The CLI and the MCP server don't link against Security.framework at all. When they need a key, they spawn jointchiefs-keygetter as a child process, read the key from its stdout, use it for one request, and drop it.

Why the extra binary? Keychain ACLs are bound to the signing identity of the requesting process. If the CLI and MCP server each asked the Keychain directly, every update that re-signs those binaries would invalidate the stored keys and prompt the user again. Concentrating Keychain access in one stable-identity binary means you add keys once and they survive every update.

The MCP server (jointchiefs-mcp) talks to exactly one thing: the parent process that spawned it. Communication is JSON-RPC over stdin/stdout. It never binds a TCP port, never listens on a Unix socket, never accepts HTTP, never sends telemetry.

This isn't a configuration choice — it's an architectural invariant. The code has no HTTP, SSE, or WebSocket server at all. Every security assumption in this product depends on the MCP client owning our stdio by definition. If you don't trust the client that spawned us, nothing else matters.

When you run a review, the only outbound network traffic is to the LLM providers whose API keys you've enabled: OpenAI, Google Gemini, xAI Grok, Anthropic, and optionally Ollama (which is usually local). No analytics, no error reporting, no update-check pings to our servers — because we don't have any.

Provider responses land in a local transcript file on your Mac. We don't cache them anywhere else. You can delete transcripts whenever you want; they have no external representation.

Signing	All four binaries (jointchiefs, jointchiefs-mcp, jointchiefs-keygetter, jointchiefs-setup) are signed with an Apple Developer ID.
Notarization	The DMG and all four binaries are notarized by Apple — Gatekeeper validates every one before launch.
Updates	The macOS app updates via Sparkle, which verifies an EdDSA signature on every update payload before installing.
CLI / MCP updates	The CLI and MCP server binaries are versioned alongside the app and replaced atomically on update.
Source audit	Entire repo is MIT-licensed at github.com/djfunboy/joint-chiefs. Reproducible local builds via swift build -c release.

We protect against

• API keys leaking to disk in plaintext, into shell history, or into the MCP wire protocol.
• Keys being invalidated by routine updates (stable-identity keygetter).
• Rogue processes reading the MCP server's input — the stdio-only invariant means the parent process is the only speaker.
• Network-based supply-chain attacks on the update path — Sparkle EdDSA verification catches tampered payloads.
• Silent error-reporting or analytics — there are none, so there's nothing to tamper with.

We don't protect against

• A malicious MCP client. The client owns our stdio by construction — we trust it at spawn time.
• A compromised provider. If OpenAI's API is breached, your review code is in that breach. Choose your providers accordingly.
• Local malware that already has your user account. Keychain access-while-unlocked means anything running as you, unsandboxed, can eventually trigger the keygetter. That's a macOS-level concern, not an app-level one.
• Shoulder surfing, screen recording, or unrelated exfiltration vectors outside this app's boundary.