Natively security and data flow

The architecture in one picture

Natively has no meeting bot and no web app. It runs on the computer you take the call on, captures your microphone and the computer's system audio itself, and writes everything it produces into a database in your user profile. Meetings are not uploaded to a Natively account. The only question for a reviewer is which outside services each setup talks to, and that is something you choose.

Three setups, three data paths

Two details change this table in practice. First, if nothing is configured when the first meeting starts, a 30-minute free trial begins by itself and uses the hosted Natively API, so set up your own keys or local models before that meeting if the hosted path is not acceptable. Second, the privacy policy states that the Natively API does not keep the content of requests, only operational metadata such as time, plan and quota use. With your own keys, the provider's own terms apply instead. The private meetings with local AI guide walks through the fully local setup.

Where meetings are stored on macOS and Windows

Each meeting, with its transcript, generated notes, your typed notes and any screenshots, is written to a SQLite database in the app's folder inside your user profile. On macOS that folder sits under ~/Library/Application Support; on Windows it sits under %APPDATA% (AppData\Roaming). The vector index used for search is stored alongside it. You can search and export meetings as Markdown, JSON, text, HTML or PDF, and deleting a meeting also turns off its share link if it had one.

Natively does not add its own encryption to that database. Any process or person able to read files as your user account can read the meetings, so the control that matters is disk encryption: FileVault on macOS, BitLocker or Device Encryption on Windows. Treat backups and synced copies of the profile folder as being as sensitive as the meetings themselves.

How keys and tokens are kept

safeStorage behaves differently on each system. On macOS it keeps its encryption key in your login Keychain. On Windows it uses DPAPI, which binds the key to your Windows user account. On both, the files cannot be decrypted from another account. If the operating system's key store is unavailable, provider keys are kept in an app-managed encrypted file instead. That keeps them out of plain text but protects them less well than Keychain or DPAPI, so keep the system key store working on managed machines. Connector tokens never use that fallback.

Every network call the app makes

Automatic sending rules post notes to Slack, Notion or a CRM once they are ready, for every meeting or one folder, and remember what they already sent so a regenerated note is not posted twice. Webhook deliveries are signed under the Standard Webhooks scheme (HMAC-SHA256 with a per-endpoint secret), go out from the app itself, and therefore only run while Natively is open. A failed delivery is retried twice and then dropped with a message in Settings. The integrations page lists each connector in detail.

Local servers on the machine

• MCP server. Off by default. When you turn it on in Settings › Connectors it listens on 127.0.0.1 only, requires the bearer token shown in Settings, refuses requests carrying a browser Origin or a non-loopback Host, and offers four read-only tools. See the MCP page.
• Local API. Runs only while at least one personal API key exists. Same loopback binding, GET requests only, and every request needs a key.
• Phone Mirror. Listens on this computer only unless you confirm that it may accept connections from your local network; the phone joins with a token carried in the pairing QR code.

Loopback is not a wall against other software running as you, which is why each of these servers checks a token on every request. Leave the MCP server and the local API off on machines that do not need them.

Screen-share protection, as each system implements it

One switch controls it: the ghost toggle in the launcher, Settings and the quick-settings panel. It is off by default and reads Detectable, and in that state Natively's windows show up in a screen share or recording like any other window. That is deliberate, for demos and support captures.

macOS. Turning it on marks every Natively window with the system's no-sharing flag (NSWindowSharingNone, through Electron's content protection). A native sweep applies the same flag to file pickers, message boxes and pop-up menus the app opens, and the flag is applied again after the Dock icon is hidden, because macOS can reset it at that moment. The Dock icon is hidden while the switch is on.

Windows. The same switch calls SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE on each Natively window and dialog, and removes the launcher's taskbar button. Exclusion needs Windows 10 version 2004 or later. On older builds the flag falls back to showing the window as a black rectangle in captures rather than leaving it out.

On both systems this only works against capture paths that respect the operating system's flag. Zoom, Teams and Google Meet normally do, with a known exception for Zoom's hardware-accelerated sharing described in the screen-share docs. It cannot hide anything from a camera, a phone, a person in the room, or software that inspects running processes, so test it with your own tools. Settings also has a disguise option that changes the name shown in Activity Monitor or Task Manager (for example Terminal on macOS, Command Prompt on Windows); teams that inventory software by process name should know it exists.

Permissions each operating system asks for

Builds, updates and source

macOS releases are produced by a release workflow that signs the app with an Apple Developer ID certificate and has Apple notarize it, for Apple Silicon and Intel. Windows builds are x64. Updates come from GitHub Releases and are downloaded only after you choose to install them. The desktop code is public on GitHub under the Natively Personal Use Source License, so a reviewer can read how each path on this page is implemented; Pro features sit in a private module that is not public.

What Natively does not have

• No SOC 2 report, ISO 27001 certificate, HIPAA attestation or any other third-party security certification. If your procurement process requires one, Natively does not meet it today.
• No encryption of the local meeting database by the app itself; protecting it is the job of disk encryption and account security.
• No end-to-end encryption for share links. Shared notes are stored readable on Natively's server so the page can be served, and anyone with the link can open it until you turn it off.
• No in-app switch for the Google Analytics events in the current version; turning usage statistics off does not stop them.
• No Linux version. Natively runs on macOS 12 or later and on Windows 10 or 11 (x64).

Checklist for your IT team

1. 1Pick the data pathDecide between the hosted Natively API, approved provider keys, or local models, and record which outside processors that puts in scope.
2. 2Configure before the first meetingEnter keys or select local models before any meeting starts, so the automatic trial never routes audio through the hosted API.
3. 3Require disk encryptionFileVault on every Mac and BitLocker or Device Encryption on every Windows PC that runs Natively, because the meeting database is not encrypted by the app.
4. 4Set the telemetry positionSwitch off usage statistics if policy requires it, and note what remains: the analytics events from the app window, the one-time install ping, license checks and update checks.
5. 5Decide on connectors and share linksAgree which connectors staff may sign in to, whether automatic sending rules are allowed, and whether public share links are acceptable for your data.
6. 6Keep local servers offLeave the MCP server and the local API off unless someone needs them, and confirm Phone Mirror stays on loopback.
7. 7Test screen sharing yourselfIf staff rely on screen-share protection, check it in your conferencing tools on both operating systems before trusting it.
8. 8Write down the reporting routeSecurity issues go to security@heynatively.com and privacy questions to privacy@heynatively.com.

Reporting a vulnerability

Email security@heynatively.com and do not post the details in a public GitHub issue. The security policy in the repository says reports are acknowledged within 72 hours on weekdays, that disclosure is coordinated with a default 90-day window, and that fixed issues are published as GitHub Security Advisories with credit if you want it. There is no paid bounty. In-scope areas include license validation, the IPC bridge, audio and screen capture, the update mechanism, Phone Mirror pairing and local data storage. For questions about personal data, write to privacy@heynatively.com or read the privacy policy.