Security & Data Handling

Effective date: 25 September 2026 · Version 5

This page describes how DiffGuardian, operated by Athleon Labs Inc., handles your code and data. It is an informational disclosure rather than an agreement, and it is written to be specific enough to be checked.

The architecture is the control

DiffGuardian is a desktop application, not a hosted service that reads your repositories. The most important security property follows from that shape:

There is no endpoint on our servers that accepts source code, diffs or repository contents. Not a disabled one, not a rate-limited one — none exists. Our API surface covers accounts, subscriptions and legal acceptances. Reviews are produced on your machine.

Where your code goes

Configuration	Where your code goes
Your own provider key (Anthropic, OpenAI, …)	Directly from your machine to that provider, over TLS, under your agreement with them
A local model (Ollama, LM Studio, llama.cpp or vLLM)	Stays on your machine
On-device embeddings and code indexing	Stays on your machine
In every case	Never to Athleon Labs

When you use your own provider key, that provider's terms and data-retention policy govern the processing — including whether they retain prompts, for how long, and whether they train on them. DiffGuardian sends the request with your key and nothing else; it does not request zero-retention handling on your behalf, so the retention that applies is whatever your account with that provider is configured for. We recommend reviewing those settings with your provider directly.

On your machine

• Credentials — provider keys and access tokens are stored on your device only in encrypted form. They are encrypted with a key held in your operating system's secure storage — the Keychain on macOS, DPAPI on Windows, or a Secret Service keyring (such as GNOME Keyring) or KWallet on Linux — and are never saved in plain text and never transmitted to us. If no such secure storage is available on your system, the application refuses to save the credential rather than storing it unprotected.
• Local data — projects, indexed repository text, reviews, draft comments, pull-request metadata and the on-device index are stored in a local SQLite database in your user library, in plaintext. The application does not encrypt that file itself; its protection is your operating system's full-disk encryption (FileVault, BitLocker, LUKS) and your user account's file permissions — the same protection as the source checkout it was built from. Settings → Erase local data deletes it.
• Filesystem access — file reads are confined to directories you have explicitly pointed the application at: local project working copies, knowledge-base folders you added, and folders you chose in a native picker. Paths are resolved through their real location before the check, so a symbolic link cannot be used to read outside those roots.
• Model-driven reads — during a review the model can request repository files. Those requests are subject to the same confinement, plus a denylist for sensitive paths, and every result is scanned for credential-shaped strings before it can enter the model's context. Tool output is treated as untrusted data, never as instructions.
• Secret scanning — a rule engine derived from the gitleaks rule set runs locally to catch credentials in the material being reviewed.

Application hardening

• The renderer process has no Node.js or filesystem access; it is sandboxed and context-isolated, and all privileged operations cross a narrow, typed bridge.
• A strict Content Security Policy applies, and navigation is restricted to the application's own origin — external links open in your system browser.
• Developer tools are disabled in production builds, which are minified and ship without source maps.
• macOS releases are code-signed and notarised with Apple; Windows builds are not yet code-signed (Windows SmartScreen may warn on first run). Updates are served over TLS from an immutable, versioned feed.
• Paid entitlement is carried by a short-lived token signed with an Ed25519 key and verified in the application's main process against a public key. The application can verify entitlement but can never mint it.

Diagnostics

• Error reports (Sentry) are scrubbed before they leave your machine: token-shaped strings are redacted, URLs are reduced to their origin, home-directory paths are removed, and integrations that would capture screenshots, console output, local variables or surrounding source lines are disabled.
• Crash memory dumps are never transmitted. A native crash writes a dump locally; what we receive is a small structured summary — exception code, faulting address, loaded module names and instruction offsets. The full dump is only ever attached if you explicitly consent in a dialog that says what it may contain.
• Product analytics (PostHog) — the desktop app's own product-usage analytics are opt-in, anonymous and event-level, tied only to a random per-install identifier: they record which features were used, never what they were used on. Separately, our servers send PostHog a small number of billing lifecycle events (for example, a completed checkout or a cancelled subscription). The person identifier attached to those events (PostHog's distinct_id) is pseudonymous, not anonymous — a one-way hash of your account id, never the id itself. An organisation's billing event that no member triggered — one from a background billing sync or a Stripe webhook — uses a fixed system identifier instead, and is filed under your organisation as a PostHog "group". Some of these events also carry your organisation id in the clear as a separate field, and a billing event may also carry a Stripe customer, subscription or invoice reference, your subscription's plan tier and billing interval, or a seat quantity or member count — never a dollar amount. A few also carry a short fixed label, such as why a chargeback happened, or a count, such as how many duplicate subscriptions were found — never free text you wrote.

None of these carry your code by design, and the scrubbing is covered by automated tests that plant realistic credentials, diff headers and prompt text and assert they cannot reach a payload.

Our infrastructure

Account and subscription data is held in a managed PostgreSQL database with encryption at rest, accessed over TLS. Authentication is delegated to Clerk; payments to Stripe, which is PCI-DSS Level 1 certified. We do not receive or store full payment card numbers. Administrative access is limited to personnel who need it.

Third-party components

DiffGuardian includes open-source software. Every component we distribute is listed, with its licence, copyright notice and full licence text, inside the application under Settings → About → OSS Licenses. Those notices ship with the application because that is where the licence obligation attaches — to the copy you received.

For vendor review and procurement we publish the same inventory in machine-readable form:

• CycloneDX SBOM — diffguardian.ai/legal/sbom.cdx.json
• Attribution list (JSON) — diffguardian.ai/legal/oss-attribution.json

Both are generated from the components the shipped application actually contains — packages packed into the application bundle plus packages compiled into it — rather than from a dependency manifest, so they describe what is distributed rather than what is declared. Each is regenerated with the release it describes; the SBOM names the version it applies to. If you need a different format, or an SPDX document, email support@diffguardian.ai.

Reporting a vulnerability

We welcome reports and will not pursue legal action against good-faith security research that respects user privacy, avoids service disruption, and does not access or modify data that is not yours.

Email support@diffguardian.ai with enough detail to reproduce the issue. We aim to acknowledge within three business days and to keep you informed until the issue is resolved. Please give us a reasonable opportunity to remediate before public disclosure.

Incidents

If a breach affects your personal information, we will notify affected users within 72 hours of confirming it and any regulator as required by applicable law, with what we know, what we are doing, and what you should do.

Subprocessors and agreements

The providers that process account data on our behalf are listed in the Privacy Policy. A data processing agreement is available on request from support@diffguardian.ai.

Questions

Athleon Labs Inc., Manitoba, Canada — support@diffguardian.ai