Security

Last updated July 27, 2026

Usage Radar minimizes the blast radius first: raw prompts, source code, provider secrets, and encryption keys are not available to the normal backend or support tooling.

Local data boundary

• No prompt retention: parsers allowlist timestamp, model, token, cache, tool-call, estimated-cost, session, and project fields. Prompt and response bodies are discarded before normalized storage.
• No Usage Radar API key: browser folder access is granted by the operating system picker and can be revoked by removing the saved handle.
• Loopback only: the optional connector listens on 127.0.0.1, not the LAN, and serves normalized read-only telemetry.

Zero-knowledge sync

Privacy-max sync encrypts normalized records on an enrolled device with AES-GCM. The device key is not sent to the service, so servers store ciphertext and cannot read its contents. Cloud-readable intelligence is a separate, revocable consent mode and is never implied by enabling encrypted sync.

Threat-model boundaries

• Authentication: passwordless identity is verified server-side and persisted in HttpOnly, Secure, SameSite cookies. Protected routes re-check the user; routing middleware is never the sole gate.
• Multi-tenancy: ownership and organization membership are checked server-side. Database row-level security is enabled for customer tables; service-role access stays server-only.
• Billing: checkout uses configured Stripe Price IDs. Entitlements are granted only by signed, persisted, idempotent webhooks—not by a success URL.
• Local connector: loopback binding, strict Host and Origin allowlists, read-only endpoints, content allowlisting, and no default outbound sync.
• Provider credentials: direct browser or local requests only. The production relay is disabled.
• Administration: platform roles are separate from organization roles. Admin tables have no client policies; sensitive actions require server authorization, a reason, and immutable audit events.

Application controls

Security headers include a restrictive Content Security Policy, clickjacking denial, content-type sniffing denial, strict referrer handling, and disabled camera, microphone, geolocation, payment, and USB permissions. Mutations check same-origin requests and validate bounded inputs.

Payments and webhooks

Stripe signatures are verified against the raw request body. Event IDs are persisted before processing, duplicates are tolerated, older subscription events cannot overwrite newer state, and failed events remain replayable. Payment redirects never provision access.

Desktop release security

Production desktop distribution requires platform code signing, macOS notarization, signed update metadata, hash verification, context isolation, renderer sandboxing, strict IPC validation, and a rollback-aware release process. Unsigned development artifacts are not represented as production installers.

Security reports

Email security@autopayradar.com with impact, reproduction steps, and affected version. Do not include real customer data or secrets. No certification or bounty program is claimed unless separately published.