Legal

Security

Last updated 9 November 2026.

Recordist's security model is simple to state: the meeting never leaves the machine by default, and nothing on the machine can reach it without your user account's permissions and a token you hold. We do not claim the software is unbreakable; we claim that the design keeps the sensitive material where you can control it.

Architecture

• No server-side processing. Audio capture, transcription, search and (with the local model) note generation all run in the desktop process. There is no Recordist backend that stores or relays meeting content.
• Loopback addresses. The local API (port 47321) binds to 127.0.0.1. The MCP HTTP transport (47322) and the A2A endpoint (47323) bind there too, unless someone starts the gateway with a different --host. All three reject requests carrying any other Host. On 127.0.0.1 they are unreachable from the network, including your LAN.
• Token authentication. Every request to the local API (47321) that reads or changes meetings must carry a bearer token created on first launch and kept in the app's data folder, readable by your user account only. The gateway's MCP HTTP and A2A ports (47322, 47323) are closed unless you start the gateway with --http or --a2a, and from gateway 0.1.5 they require the same token on every request, except the A2A Agent Card, which lists skills and no meeting data. Gateway 0.1.4 and earlier did not check the token on those ports, so while one of them ran, any program on the machine, including one run by another user account, could read meetings through it; if you use them, update with npx -y @recordist/gateway@latest. The gateway's default connection over stdio has no port. Each connected program has a token of its own with only what it needs: the Chrome extension pairs through a short-lived code, and its token cannot read, change or delete meetings. Settings → Integrations lists every connected program with Revoke. A token never needs to leave your machine and should never be shared. Details for developers are in the Developers section.
• Explicit consent to record. Recording starts only when you start it yourself (Record on the confirm prompt, in the menu bar or in the app window, or the global hotkey), for an app you added to Record without asking for in Settings → Detection, or from a local API request that carries the token while Allow agents to start recordings is on in Settings → Integrations. Both of those settings are off by default.
• Minimal permissions. The app asks for microphone and system-audio permission to record, and calendar and notifications optionally. To read meeting window titles for detection it uses the Screen Recording or Accessibility permission if you grant one; Settings → Detection has a button for each. You can turn window titles off there, but when a browser starts using the microphone the app still reads that browser's window titles to tell which meeting site is open. It does not request contacts or location. The extension is restricted to the supported meeting sites and the loopback address.

Data at rest

• Files are protected by your operating-system account. We recommend full-disk encryption (FileVault, BitLocker, LUKS).
• API keys for third-party AI providers are stored in the OS keychain, never in plain files, exports, diagnostics or logs.
• The app's log contains no transcript text and no meeting or calendar titles (versions before 0.3.12 wrote titles). It stays on your machine and is sent to no one unless you choose to send a diagnostics file.

Data in transit

The app makes outbound connections for the speech-model and notes-engine downloads, the update check and update download, from version 1.0.3 one first-launch mark per install (once, carrying only the version and the platform in its path), from version 1.0.7 three first-step marks (each once, carrying only the step, the version and the platform in its path; they have their own switch), the withdrawn-keys list (with each update check while a licence key is stored; the request carries no key, id or account), from version 1.0.5 the automatic renewal of a Pro subscription (with the update check: the key once with a one-way code of a random secret kept in the keychain, then only the key's id and that secret), from version 1.0.9 the key for a purchase started in the app (only after checkout is opened from the app, for 24 hours at most, sending only a random code the app made for that checkout; the page the app opens carries only a one-way code made from it, which cannot collect the key; that one-way code can appear in our host's standard server logs and goes to Stripe with the order), from version 1.0.10 your email for the Pro key, only if you give it when Recordist first opens or after the update (to recordist.app: the address, a random code for this install, the platform, the app's version, your time zone and which words you saw, tried again while offline for up to 7 days), calendar feeds you add, an AI provider you configure with your own key, your own Ollama server if you set its address to another machine, and, on a Mac whose organisation turns it on, that organisation's own archive storage. The app's own downloads, the update requests, the archive and the Anthropic and OpenAI APIs use HTTPS. A calendar feed you add is reached at the address you give, which can be plain http. A notes server on another machine is reached only over https, unless an organisation allows plain http in its managed settings. The speech models, the voice-activity model and the built-in notes engine are checked against an exact size and a SHA-256 built into Recordist when the app downloads them, and a file that does not match is deleted. The notes model is checked by the notes engine itself, against the checksums Ollama's registry publishes. App updates are installed only if their signature matches the public key built into the app. Most outbound requests are written to the Privacy Ledger in the app; the ledger article lists what it does not record yet.

Licensing

Licence keys are Ed25519-signed and verified offline with a public key embedded in the app. The private signing key is held by us, outside our source code, and is never present on user machines. A compromise of the website or the licence service therefore cannot expose meeting data, because none is held there.

Supply chain

• macOS builds are signed with our Apple Developer ID (Team ID JNC57WQK69) and notarised by Apple, and a copy changed after it was signed runs on the Free plan and says so. The Windows installer is signed through Microsoft's Artifact Signing service (Authenticode, SHA-256, with an RFC 3161 timestamp from Microsoft), and the publisher Windows shows is Havihi Digital Inc., the company that makes Recordist. Its certificates are short-lived; the timestamp keeps the signature valid after the certificate expires. The app it installs is signed too. The installer's SHA-256 is on the download page. SHA256SUMS.txt covers the latest update archive. To check the Mac app yourself, run spctl -a -vv /Applications/Recordist.app: it answers accepted and source=Notarized Developer ID, with our Team ID, JNC57WQK69, at the end of its origin line.
• Dependencies are pinned through lockfiles, and updates to them are proposed automatically.
• The website loads no third-party scripts, and its fonts are served from recordist.app too; nothing on a page comes from another host. The films on this site are served from our own domain with the browser's built-in player.

Website and checkout

The site is static and served with security headers (no framing, no MIME sniffing, strict referrer policy). Payment pages are hosted by Stripe; card details never touch our infrastructure. Keys for purchases are issued only for payments verified with Stripe. Site forms limit repeated tries, and anything that looks like an API or licence key is removed before a support message is stored or sent to the assistant. Installers download from our own domain, with a limit on repeated downloads.

What we do not do

• No analytics, tracking or crash reporting in the app, apart from one first-launch mark per install from version 1.0.3 and three first-step marks from version 1.0.7, each sent once with no identifier; the first steps have their own switch in Settings (privacy policy, section 1.2). The website counts page views without cookies or identifiers, as the privacy policy says.
• No accounts, so no passwords to lose.
• No bots joining meetings, so no meeting-platform credentials or OAuth grants.

Reporting a vulnerability

Please email security@recordist.app with a description, steps to reproduce and the app version. We acknowledge reports within 3 business days and aim to ship a fix for confirmed high-severity issues within 14 days. We ask that you give us reasonable time to fix before disclosing publicly, and we will credit you in the changelog if you wish. There is no paid bounty programme at this time. Please do not test against other people's machines or data. The vulnerability disclosure policy sets out the scope, the time we ask before publication and the safe harbour for good-faith research, and /.well-known/security.txt carries the same contact (RFC 9116).

Supported versions

Security fixes are released for the current minor version. The Free plan receives them on the same day as paid plans.

Trust Center

The Trust Center has the plain-language version of this page: the traffic table, permissions, retention and deletion, and how to report a problem. For a vendor review it also has the one-page security brief, the pre-filled questionnaire and the data processing position.

Changes

This page is updated as the architecture evolves. Material changes are noted in the changelog.