Security architecture

Local-first narrows the attack surface. It does not make risk disappear.

Daisy records, transcribes and stores meetings on your Mac. There is no Daisy account or hosted meeting-data plane. This page documents the boundary that creates, the controls around it, and the limits you should understand before using Daisy with sensitive conversations.

01 / Local

Your Mac is the data plane.

Audio capture, transcription, the archive and default local workflows run on the Mac. Daisy does not copy meetings to a Daisy server.

02 / Optional

Egress is an explicit choice.

If you enable a cloud summarizer or destination, the selected content goes directly from your Mac to that provider under its security terms.

03 / Inspectable

The controls are source-visible.

Daisy is Apache-2.0 licensed. The app, entitlements, local server and update configuration can be inspected in the public repository.

Controls

What Daisy actively protects

Application integrity

Public builds are Developer ID signed, Apple-notarized and use the Hardened Runtime. Sparkle updates are protected by a pinned EdDSA public key; Daisy verifies the signed update before installation.

Secrets and permissions

Provider tokens are stored in macOS Keychain, not in meeting files. Microphone, calendar and other sensitive capabilities remain subject to macOS Transparency, Consent and Control permissions.

Local MCP boundary

The MCP server binds to loopback rather than a public interface. It validates the Host header, rejects non-loopback browser origins, avoids wildcard CORS and supports an optional bearer access token.

Minimal vendor infrastructure

Daisy has no user account service, meeting database or remote admin path. Removing those systems eliminates an entire class of central breach and cross-tenant access risk.

Explicit limitations

What this model does not promise

Daisy is not App Sandbox enabled.

Dictation needs to insert text into other applications, which is not compatible with the App Sandbox boundary used by Mac App Store apps. Daisy is distributed outside the App Store and relies on signing, notarization, Hardened Runtime, macOS permissions and open review of the code instead. This is a trade-off, not a security guarantee.

An unlocked, compromised Mac is outside the assumed boundary.

Daisy does not add its own encryption layer to local meeting files. It assumes the macOS user-session boundary, disk encryption and your device access controls remain intact. Malware or another process with sufficient access in that session may be able to read local data.

Loopback is local, not unreachable.

A browser can send traffic to services on 127.0.0.1. Daisy therefore treats Host, Origin, CORS and optional token checks as meaningful defenses. Users handling higher-risk material should enable MCP authentication and connect only trusted clients.

Connected providers become part of your boundary.

When you choose OpenAI, Anthropic, Notion or another external service, that service receives the content needed for the request. Daisy cannot extend its local guarantees to the provider. See the detailed privacy disclosures.

Verification

Inspect the implementation

Security policy and full threat model — supported versions, assumptions and coordinated disclosure.
MCP server — loopback binding, browser-origin validation and token authentication.
Application entitlements — the capabilities requested by the app.
Keychain storage — storage path for provider credentials.
Complete source repository — build instructions, license and release history.

Report a vulnerability

Please report security issues privately.

Email a clear reproduction and affected version with the subject prefix [SECURITY]. We aim to acknowledge reports within five working days and coordinate disclosure after a fix is available.

Email essazanov@pm.me