Where your code goes (and where it doesn't)
Most AI code-review products are a service. You install their GitHub App, grant it read access to your repositories, and from that moment your diffs flow through their servers, their queues, their logging, and their model accounts. The review is good or it is not. The architecture is the same everywhere: a third party sits between your code and the model, and you trust that party's infrastructure, retention policy, and breach record.
PR Radar is built on a different premise: the product is your Mac. There is no server of ours in the path of your code. This post walks through what that means concretely, what cryptography holds it together, and, because security writing that hides its limits is marketing, what it does not protect you from.
The shape of the thing
PR Radar is a macOS menu-bar app. It polls GitHub with your token, reviews pull requests by running a coding agent on your machine under your own model subscription, and posts reviews back as you. Jira, when you wire it, is called directly with your credentials. At no point does a PR Radar server see a diff, a token, or a review.
That single fact reorders the whole threat model. Review execution and credentials stay on your Macs. If you enable Pro sync, our infrastructure holds only end-to-end encrypted history and transcript objects whose key remains with your account's Macs; a service breach exposes ciphertext, not readable code. Readable data lives with your Macs and the services you already trusted before we arrived: GitHub, Jira, and your model provider.
Credentials: the keychain, and nothing else
Tokens live in the macOS Keychain. Never in a config file, never in a shared container, never in a dotfile. Each GitHub account's token is stored under its own key and used only for that account's work. The isolation is deliberate, so a work token can never touch your personal repositories, and one client's token can never touch another client's, because something reached for a default.
When a review runs, each tool the agent may call (the diff reader, the ticket fetcher, the metrics query) receives only the credentials scoped to it, through its environment. The audit trail that records every tool invocation records the command and its arguments and deliberately nothing from the environment, because the environment is where the credentials are. The transcript will tell you a tool ran, what it was asked, how long it took, its exit status, and, for failures, its last words on stderr. It will never echo a secret.
The phone link: end-to-end, including against us
PR Radar's companion app can watch and steer reviews from an iPhone. The traffic rides a relay, and the relay is designed to be unable to read it.
Every frame between phone and Mac is sealed with a fresh, per-frame X25519 key exchange, an HKDF derivation, and ChaCha20-Poly1305. Every frame is signed with the sender's long-term Ed25519 identity over a canonical, domain-separated byte string, so a frame from one part of the protocol cannot be replayed as another, and checked against a nonce replay cache inside a bounded freshness window. Pairing is a short code entered once, folded into the key derivation as salt, and confirmed by comparing a short authentication string on both screens. That comparison is the step that closes the man-in-the-middle door. Because the ephemeral key is new for every frame, capturing traffic today and stealing a device tomorrow does not decrypt yesterday.
The consequence is written in the code's own words: a server in the middle cannot read the payload. That includes our own tunnel edge. The control plane that routes push notifications stores and forwards bytes it cannot read. Pushes arrive at Apple's servers sealed and are decrypted on the phone, in the notification extension, with keys only your devices hold. The phone itself carries no GitHub or Jira credential at all; it asks your Mac, and your Mac answers.
The team lobby: read-only by construction
The optional status dashboard, the page your teammates can watch reviews on, is served from your Mac through the tunnel. It sits behind a password or a Sign in with GitHub door that admits only active members of a GitHub org you name; their OAuth token is used for exactly one membership question and then discarded, and what survives is a session your Mac signed itself. Everything the lobby serves is read-only by construction: the pages are rendered exclusively from GET clients, and the code that can write to GitHub is never imported there. The pull-request console serves only pull requests the dashboard itself currently lists; the run-log console serves only CI jobs vouched for by those pull requests. Anything else, and any visitor without the cookie, gets the same flat 404 a port scanner gets. Your own draft pull requests, which PR Radar can review privately before you mark them ready, never appear on any teammate-facing surface at all.
The supply chain
The app ships with the hardened runtime, no debugger-attach entitlement, a Developer ID signature, and Apple notarization. Updates verify four ways before installing: the download's SHA-256 must match the published manifest, the bundle's signature must verify strictly, the signer must be the expected identity rather than merely a valid one, and Gatekeeper itself must accept the result as notarized. The protocol library is vendored into the repository, so the build is self-contained rather than resolved from the network at build time.
What PR Radar cannot protect you from
Honesty is part of the perimeter, so: the model provider sees your diffs. That is the review. But it happens under your own account and terms, not through our keys. GitHub sees what GitHub always sees. The dashboard password is a shared secret; treat it like one, or use the org sign-in, where removing someone from the org removes their access. The transport gives per-frame forward secrecy, but if a device's long-term identity key is stolen, you revoke it by unpairing. There is no self-healing ratchet pretending otherwise. And the floor under everything is your Mac's own security; PR Radar inherits it and cannot exceed it.
The comparison that matters
| Hosted AI reviewers (as a class) | PR Radar | |
|---|---|---|
| Your GitHub token / app grant | Lives in the vendor's cloud, org-wide | Lives in your keychain |
| Where diffs are processed | Vendor servers, then a model | Your Mac, then your model account |
| What a vendor breach exposes | Read access to your repositories | Nothing. There is no server holding anything |
| Who can read the remote-control traffic | The vendor, structurally | Nobody, including our own relay |
| Retention | The vendor's policy | Your enrolled Macs' disks; Pro's account archive stores only end-to-end encrypted objects |
None of this says a hosted reviewer is careless. It says the trust is structural: with a service, security is a promise about their operations; with PR Radar, it is a property of the architecture. And the audit trail (full transcripts of every tool call, a diagnostics ring that names every refusal) stays on your enrolled Macs, where you can read it.
Every claim in this post was checked against the shipping source before publication.