Vauta is distributed as source code only (no signed or notarized downloads): you build it from a tagged commit, see Verifying what you run.

To update, run ./scripts/update.sh in your clone (README, "Update"): it installs the newest release only if its tag verifies as below. From a checkout of 0.9.3 or earlier, run git checkout main && git pull once first: versions before 0.9.3 have no script, and the one in 0.9.3 can stop with "unbound variable" when a newer release is there. That one pull is not covered by the signature check: update.sh, the fingerprint in it and .github/allowed_signers then come from main as GitHub serves it, not from a verified tag (merges on main are signed by GitHub, not by the maintainer's key, so git verify-commit does not cover them either). If that matters to you, check the file's key independently as in Verifying what you run and read the script before you run it; after that update this folder is at a verified release tag, and the next update starts from its files.

Please report vulnerabilities privately, through GitHub's private vulnerability reporting: github.com/MaquinaTech/Vauta/security/advisories/new. Do not open a public issue, discussion or pull request for a security problem.

Include what you can: the Vauta version (Settings → About), the macOS version, the steps to reproduce, what you expected and what happened, and the impact you see. Do not include real meeting content.

Vauta is maintained by one person, so these are targets, not guarantees:

These targets meet the OpenSSF Best Practices criterion that no medium or higher vulnerability stays unpatched more than 60 days after it is publicly known; ours count from your report, which is stricter. If a fix needs longer (for example a change to a persisted format that must stay compatible), we tell you why and publish a mitigation in the meantime.

Vauta has not been independently audited (see Audit status).

We coordinate the disclosure date with you, publish a GitHub security advisory with the fix, and credit you unless you prefer otherwise.

In scope: the Vauta app and command-line tool, the scripts in scripts/, and the release workflow. Out of scope: vulnerabilities in model servers (LM Studio, Ollama and others), in macOS or Apple frameworks, and findings that require the attacker to already control your user account while Vauta is running (see the threat model).

Vauta handles meeting transcripts and, for speaker separation and the optional saved voices, voice-derived data (speaker embeddings and voice fingerprints, which are biometric data). Both can be very sensitive. Vauta is designed for one person on their own Mac. Audio itself is never written to disk. The voice data rules are in Speaker separation and voice data.

Separating the speakers of a meeting produces voice-derived data (embeddings). The rules:

• They are computed on this Mac by two models bundled in the app. Each model folder is checked against a pinned SHA-256 (a hash over every file name and content) before Core ML loads it; a changed, missing or extra file, or a symbolic link, refuses to load and the recording continues without speakers. The check guards a damaged or tampered copy; an attacker who can rewrite the signed app bundle is out of scope, as for the rest of the app. Core ML also compiles the verified files for the Neural Engine into its own cache in the app's Caches folder; that derived copy holds no meeting data and is not hashed (tampering with it needs write access as your user, which is out of scope below).
• Window embeddings are written only to the encrypted store (diarization_windows, in the encrypted journal and snapshot), are deleted when the speakers are finalized (or, if that fails or the recording crashed, when the meeting ends or at the next launch, whichever comes first; or with their meeting), are deleted when a backup that holds an unfinished recording is restored, and are never logged, exported, indexed, put in a prompt or sent. WindowRecord prints no embedding.
• Malware running as your user while Vauta is open can read them from memory like the rest of the store; that is already out of scope (below).
• The models add no code and no network path (NetworkAuditSourceScanTests covers the sources).

Suggesting who is speaking across meetings stores voice fingerprints (voice_profiles, up to 10 per person) and, while the setting is on, a voice summary per speaker with each meeting (speaker_voices). They are biometric data, so:

• Off by default; saved only by an explicit action per person, behind a consent attestation whose time is stored. The user records who agreed; Vauta cannot verify it. The paid legal review was not done: the docs say consent is the recording user's responsibility and recommend a DPIA note for organisations.
• They live only in the encrypted store (journal and snapshot), are included in encrypted backups and in Erase Everything, and are not in exports, logs, prompts, the search index, the vector cache or on the network. VoiceProfileEmbedding, SpeakerVoiceDraft and SpeakerCentroid print no vector. A source scan test (VoiceRecognitionTests) fails if a file other than the store and the matcher touches the voice tables.
• Deleting them (per person, which includes the summaries of the speakers named after them, all, with the person or with the meeting, by turning the setting off for the summaries, when a summary is 14 days old, and when a meeting's summaries are replaced) saves a snapshot at once, so neither the journal nor the previous snapshot keeps them (secure_delete zeroes the pages).
• A fingerprint of another embedding model is never compared, and the thresholds belong to one model.
• The shipped app has no command that writes voice vectors to a file: the calibration command speaker-centroids exists only in the diagnostics build, which is never distributed (and a source-scan test fails if code other than the store, the matcher and the diarization calls SpeakerCentroids.compute).
• Exfiltration of the fingerprints by malware running as the same user while Vauta is open is out of scope, like the rest of the decrypted store (below). A fingerprint cannot be turned back into audio, but it could be used to recognize that person's voice elsewhere, which is why it is opt-in.

• Malware or another process running as your user while Vauta is open. The decrypted database is in Vauta's memory, and the login keychain is unlocked for your whole session, including while the screen is locked. The Meetings lock (Touch ID or password) protects the interface, not memory.
• A key item planted before Vauta creates its store. When no store exists yet, Vauta uses a database-key-v1 item that is already in the login keychain (so a store restored next to it still opens). A process running as you that created that item beforehand, with an access list open to it, could read the key. Such a process is already in the threat above; "Erase Everything" and a restore replace the item with one only Vauta can read.
• Other accounts on this Mac, with a server on this Mac. In This Mac mode Vauta talks plain HTTP to 127.0.0.1, which is shared by every account on the Mac. While your server is stopped, a process of another account can listen on its port and receive Vauta's requests (meeting text and the server key). On a Mac shared with people you don't trust, keep the server running while Vauta uses it, or run it on another computer (Network mode, HTTPS).
• Someone using your unlocked login session. Vauta asks for Touch ID or your password before showing Meetings, but whatever is already on screen is visible, and your keychain is unlocked for any app they run.
• Rollback. Replacing vauta.db.enc and vauta.journal.enc with an older pair encrypted with the same key, or dropping whole records from the end of the journal, is not detected: it authenticates and brings back an earlier state. "Erase Everything" changes the key, so copies older than an erase never open.
• A compromised or untrusted model server. The server reads everything Vauta sends it (transcript text, notes, names). Use a server you control.
• Old keychain backups. Time Machine backs up the login keychain, encrypted with your login password, so an older backup may still contain a key that "Erase Everything" has since replaced. The store itself is excluded from backups, but someone with a copy of an old store file (for example one copied by hand), that keychain backup and the login password of that time can decrypt that copy. Erase Everything removes the key and data from this Mac; it cannot change old backups.
• Screenshots and screen sharing. Copy protection prevents accidental copying, not someone who can see the screen.
• Ad-hoc signed builds. Without a stable signature, the Keychain cannot bind the key to Vauta's identity.

• A random 256-bit key (CryptoKit), stored as a generic-password item in the login keychain: service = the app's bundle ID, account database-key-v1. Never synchronizable.
• Created only when no store exists. If the store exists and its key is missing, Vauta refuses to create a new key (that would make the store unreadable) and reports the problem. A locked keychain or a cancelled prompt never leads to a new key.
• A new store uses an item that is already there, so a store file put back next to it still opens (see the limit below). "Erase Everything" never does: it deletes the item, checks it is gone and adds a new one, and an item that appears in between makes the add fail instead of being adopted.
• kSecAttrAccessibleWhenUnlockedThisDeviceOnly is set, but the classic login keychain ignores it (it needs the Data Protection keychain, which requires a provisioning profile). In practice the item is readable while the login keychain is unlocked.

The database is an in-memory SQLite database. To save it, Vauta serializes it with sqlite3_serialize, compresses it with LZ4 (or stores it as is when that is not smaller) and seals it:

file      = "ACTA" | 0x02 | nonce (12) | ciphertext | tag (16)
plaintext = size (UInt64 LE) | method (0 = stored, 1 = LZ4) | payload
cipher    = AES-256-GCM, random nonce, AAD = "ACTA" | 0x02

The magic ACTA is a legacy format identifier from the working name. Like ACTJ (journal), ACTABK (backup) and the HKDF label acta-journal-v1, it is part of the encrypted formats and of the authenticated data, so it never changes. Stores written before the rename open without conversion.

The header is authenticated, so a tampered file or a file of another version does not decrypt. Envelope v1 (Vauta 0.1, LZFSE) is still read and is rewritten as v2 on the next save. The envelope version is independent of the database schema version.

Between snapshots, only new writes are appended (every 10 seconds while recording):

header = "ACTJ" | 0x01 | generation (16 random bytes)
record = length (UInt32 LE) | AES-256-GCM(statements), AAD = header | seq (UInt64 LE)
key    = HKDF-SHA256(database key, info: "acta-journal-v1", 32 bytes)

• The journal key is derived with its own label: the snapshot and the journal never share a key.
• The snapshot stores the generation, so a journal from another snapshot is never replayed.
• The sequence number in the AAD prevents reordering, repeating or removing records in the middle. A truncated last record (power cut mid-write) does not authenticate and replay stops there.

The index of the files you add as document sources uses the snapshot's envelope with its own key, HKDF-SHA256(database key, info: "vauta.documents.v1", 32 bytes). It is derived data: never in the journal or in backups, rebuilt from your files when it does not open, and deleted by Erase Everything and by a restore. While a file is being read, a small plaintext marker, vauta.docs.extracting, holds the source number, the file's size and date, and the first 8 bytes of an HMAC-SHA256 of its relative path (key derived from the documents key with vauta.documents.marker.v1), never its name, so a file that crashes the reader is skipped on the next launch.

• Snapshots are written to a new 0600 temporary file, flushed with F_FULLFSYNC, renamed over the old file, and the directory is flushed with F_FULLFSYNC so the rename survives a power cut.
• Journal appends use F_BARRIERFSYNC (ordered, cheap). A power cut can lose the last few seconds of a recording, never the order of what was written.
• A snapshot is taken a few seconds after edits, when the journal exceeds 8 MB, and when a recording ends.

• Plaintext buffers that Vauta controls are zeroed when released (best effort: copies made inside Foundation or CryptoKit cannot be reached).
• SQLite runs with secure_delete = ON and temp_store = MEMORY. Deleting a meeting also merges the full-text indexes and runs VACUUM.
• The process runs with umask 077. Window restoration is off. A file lock (vauta.lock, and acta.lock too while it exists) prevents two instances from writing the same store.
• Migrating from an earlier version. On open, a store with the old file names is verified with the Keychain key (read-only) and only then renamed in place, one atomic rename(2) per file, snapshot first and journal second. An interruption between the two is finished on the next open; any failure after the renames puts the old names back. Files are never deleted by the migration.

Format of a backup file (.vautabackup; backups from an earlier version are still accepted), implemented in Sources/VautaCore/Backup/:

"ACTABK" | version (1) | KDF id (1 = PBKDF2-HMAC-SHA256) | iterations (UInt32, big endian) | salt (16 bytes)
| AES-256-GCM sealed box (12-byte nonce | ciphertext | 16-byte tag)

• The 28-byte header is the GCM additional authenticated data, so changing the version, the iteration count or the salt makes decryption fail.
• Key: PBKDF2-HMAC-SHA256 (CommonCrypto CCKeyDerivationPBKDF) over the NFC-normalized UTF-8 password, 1,000,000 iterations (readers accept 600,000 to 2,000,000), 16 random bytes of salt, 32-byte output. Apple's frameworks have no memory-hard KDF (scrypt, Argon2) and Vauta takes no third-party cryptography code, so a long password is the real protection; the app requires at least 12 characters.
• Plaintext inside the sealed box: manifest length (UInt32) | manifest (JSON: format, app version, schema version, creation time, meeting count, settings length) | the settings (format 2 only) | the database image in the same packed form as the snapshot (size | LZ4 | bytes). The image is taken from the open store in one step on the store's actor, so it is consistent. A backup is authenticated but not trusted: its declared image size must fit in 1 GiB and in what LZ4 can expand to before anything is allocated, and the parsers of the image and of the store's journal are fuzzed (ParserFuzzTests).
• Settings (BackupPreferences): a binary property list of an explicit allow-list of UserDefaults keys (languages, templates, shortcuts, privacy and recording switches, the choice of where models run), each with the type it must have. No Keychain item is ever read: the server address, models, key, certificate authority and pins stay out, as does everything specific to one Mac (frames, markers, calendar identifiers). On restore a key that is unknown, of another type or too large is skipped, a payload that can't be read is ignored (the meetings still restore), and nothing outside the allow-list is ever written. Format 1 (no settings) is still read and leaves the settings alone; a reader that only knows format 1 refuses a format 2 file by its manifest. The archive version byte stays 1.
• Plaintext buffers that Vauta controls are zeroed after use; nothing unencrypted is written to disk.
• A new backup is read back from the disk and opened with its password exactly as a restore would (MeetingStore.checkBackup), in memory, before the sheet says it was saved; one that fails is deleted. Verify Backup… runs the same check on any file without restoring it, and the decrypted copy is dropped (its memory zeroed) as soon as it has been counted.
• A backup is treated as untrusted even though it is authenticated (whoever knows the password can author one). Every database connection runs with trusted_schema = OFF and cell_size_check = ON; a declared image size is capped (1 GiB, and LZ4 payloads cannot declare more than 256 times their length).
• Restore decrypts and validates in memory (authentication, manifest, schema no newer than the app's, the image's schema compared object by object with Vauta's own DDL for that version, so a backup carrying any extra or changed table, index, trigger, view or virtual table is refused before anything runs; the full-text indexes, a binary format SQLite parses whenever they are read, built again from their text before anything reads them, and refused if their FTS5 settings aren't the ones Vauta sets; SQLite integrity_check; migrations for older schemas) before touching the store. Then, with no suspension point: a new random key is stored in a second Keychain item (database-key-v1.staged); the backup is written as the new snapshot, sealed with the new key, atomically over the old one (F_FULLFSYNC, rename, directory sync); the database key item is deleted and added again with the new key and Vauta's own access list; the staged item is deleted; the journal is removed. If writing fails, the staged key is deleted and the old store is untouched. If the process stops at any step, the next launch opens the store with whichever of the two keys authenticates the snapshot and finishes the change, so the store opens with either the old data or the restored data. After success the old key no longer exists, which is the same crypto-shred as Erase Everything.
• A wrong password, a changed header or payload, and a truncated file are indistinguishable by design (GCM authentication fails); a file without the header, or cut inside it, is reported as not being a backup.
• Not protected: a backup is only as strong as its password; an attacker with the file can guess offline. A backup also carries no freshness: restoring an older backup is allowed (that is its purpose).

Deletes the snapshot and the journal, deletes the key from the Keychain, verifies it is gone, creates a new key and writes an empty store. A marker file completes the key rotation on the next launch if Vauta is interrupted. The search model (public weights, no personal data) is not part of the store and is kept; Settings → Models → Delete… removes it.

Apart from the two optional model downloads (below), Vauta's only network client is LLMClient, which talks to the model server you configured. The rules are enforced in code (LLMServerConfig, ServerAddress, ServerTrust, LLMClient). Every request, from LLMClient and from discovery, goes through one choke point, AuditedSession (see Network audit):

Discovery ("Find Servers") uses a separate session that only reaches http://127.0.0.1 on ports 1234, 11434, 8080, 8000 and 1337, with short timeouts, no proxies and no redirects. It runs when you click the button, and, while the Set up a model server guide is open, every few seconds on ports 1234 and 11434 only (it stops when the guide closes).

Speech models and on-device language assets are downloaded by macOS from Apple, not by Vauta. Vauta never listens on the network.

The other outgoing connections are the two optional models, each only after you click Download: the search model, here, and the integrated language model (next section). The search model (see PRIVACY.md) has its own session and its own rules, in SearchModelDestinations and SearchModelDownloader, and also goes through AuditedSession with the purpose modelDownload:

The integrated model (Gemma 4 E4B by Google, see PRIVACY.md) is fetched from huggingface.co only after you click Download in Settings → Models → Integrated model (or Try Again, Resume, Repair). LanguageModelDownloader uses a session made the same way as the search model's (SearchModelDownloader.makeSession), goes through AuditedSession with the purpose languageModelDownload and follows the rules above, with these differences:

Running the model adds no entitlement: Vauta compiles MLX's GPU kernels from embedded source on the first use, which runs in Apple's Metal compiler service. If Vauta mlx-selftest ever fails in a signed build, the answer is to stop and report, never to add JIT, unsigned-memory or library-validation entitlements. The procedure is in docs/SEARCH_MODEL.md.

Third-party code. MLX is the only third-party package: a fork of mlx-swift (MIT) pinned by revision, built from source. scripts/check-dependencies.sh and a test fail on any other package or revision; scripts/build-app.sh (so install.sh and update.sh) runs that check before building and builds with --force-resolved-versions, so a Package.resolved that doesn't match is a stop, never re-resolved. Bumping it follows the checklist in docs/SEARCH_MODEL.md (re-apply the patches, regenerate the kernel source, run the self-test on signed builds). Its licences are in NOTICE and THIRD_PARTY_LICENSES.txt. The pin is transitive: the fork's own submodule Source/Cmlx/mlx points to a second repository, MaquinaTech/mlx at commit d1dfda2 (branch vauta-clt), which carries the C++ part of the runtime-compilation patch; both repositories are ours and both commits are tagged (vauta-0.9.0, signed with the release key) and rulesets on both repositories block deleting or moving those tags and deleting or force-pushing vauta-clt, so the pin cannot become unfetchable.

Settings → Privacy & Security → Network Activity… lists every connection Vauta makes, so the rules above can be checked on a running app and not only read in the source.

Vauta runs in the App Sandbox with the hardened runtime and no runtime exception entitlements (no JIT, no unsigned executable memory, no disabled library validation). The entitlements, from Resources/Vauta.entitlements:

Info.plist allows local networking in App Transport Security (NSAllowsLocalNetworking) so that loopback servers work over HTTP; it does not allow arbitrary loads.

macOS ties your permissions (microphone, audio capture, calendar) and the Keychain key to Vauta's signature and bundle ID. Keep both stable.

• Your builds (the only kind there is: Vauta is source-only): run scripts/setup-signing.sh once. It creates a local signing identity in a dedicated keychain with its own password that locks after 10 minutes, so no process running as you can sign code as Vauta without that password. scripts/build-app.sh uses it automatically. (A fork with an Apple Developer account can set VAUTA_SIGN_IDENTITY to a Developer ID identity; Vauta itself publishes no such builds.)
• Ad-hoc signing (VAUTA_ALLOW_ADHOC=1) is for CI and quick tests. Each build has a different identity, so macOS asks for permissions again and the Keychain cannot tell Vauta from another app.
• Do not change the bundle ID after installing (VAUTA_BUNDLE_ID in scripts/local.env). Keychain items, the sandbox container and permissions belong to it; a new ID starts from scratch.

Check a build with:

codesign --verify --strict --verbose=2 Vauta.app
codesign -d --entitlements - Vauta.app
codesign -dvv Vauta.app 2>&1 | grep -E 'Authority|Timestamp|flags'

Vauta publishes source, not binaries, so what you run is what you built. To check it:

1. Build from a tagged release, not from a moving branch: git clone https://github.com/MaquinaTech/Vauta.git, then git checkout v<version>.

2. Verify the tag. Release tags are signed with the maintainer's SSH key (ED25519, fingerprint SHA256:exvRtcRtqxp/AHhadgXr7PAHe9itjHFPqVVCoGaOrU4), which is published as a signing key on the MaquinaTech GitHub account (its signing keys), so GitHub shows the tag as "Verified". The public key is also committed in the repository as .github/allowed_signers (principal maintainer@vauta). To check the tag locally, first confirm that the file holds the key above, independently of the checkout (the fingerprint printed here must match the one in this document as read on GitHub, and the key must be listed at the signing-keys address above):

   ssh-keygen -lf <(cut -d' ' -f3- .github/allowed_signers)   # must print SHA256:exvRtcRtqxp/AHhadgXr7PAHe9itjHFPqVVCoGaOrU4

   Then verify the tag:

   git -c gpg.ssh.allowedSignersFile=.github/allowed_signers tag -v v<version>

   It must print Good "git" signature … with ED25519 key SHA256:exvRtcRtqxp/AHhadgXr7PAHe9itjHFPqVVCoGaOrU4. Compare git rev-parse v<version>^{commit} with the commit shown on the release page. Release notes are the matching section of CHANGELOG.md.

3. Read what you build. The code is small enough to audit: docs/CLAIMS.md links every claim to a test or command, and scripts/check-dependencies.sh verifies the pinned dependencies.

4. Check the result with the codesign commands above and the Network Activity list in the app.

update.sh accepts one key: the one in the .github/allowed_signers of the checkout you already have, which must also match the fingerprint written in the script. It never moves to another key by itself. If the maintainer's key is lost, compromised or replaced, a release signed with a new key makes it stop ("is not signed by the maintainer's key", or "does not hold the maintainer's key"). Don't edit the script or .github/allowed_signers to make it pass. Check the new key yourself, once:

1. The project announces a new key in the release notes of the first release signed with it, and lists it among the signing keys of the MaquinaTech GitHub account (its signing keys). While the old key is still in the maintainer's hands, a tag signed with the old key also states the new fingerprint.
2. Confirm the new fingerprint from more than one of those sources, as GitHub serves them, not only from the checkout.
3. Verify the new release's tag by hand, as in step 2 of Verifying what you run, with the .github/allowed_signers of that tag (git show v<version>:.github/allowed_signers) and the new fingerprint, and read what changed in scripts/update.sh. Then run git checkout v<version> and ./scripts/install.sh (in your own Terminal with a local signing identity). From that release on, update.sh checks the new key.

If the old key was lost, nothing signed with it can vouch for the new one: the GitHub account and the release notes are then the only sources, so you trust the account alone.

Vauta has not been independently audited. Its security properties are backed by public tests and source code, listed claim by claim in docs/CLAIMS.md, and by your own checks (Network Activity, an outside network monitor, codesign). That is evidence, not an assurance from a third party. If you rely on Vauta for confidential work, read the code and the threat model above, and report what you find as described in Reporting a vulnerability.

The cryptography actually used, with its parameters and its known weaknesses, is reviewed in docs/CRYPTO_REVIEW.md. That review is internal, written by the project, and is not an audit.

• PRIVACY.md: what is stored, where, and what is sent.
• docs/MODEL_SERVERS.md: setting up a server on your network with TLS.
• docs/ARCHITECTURE.md: how the pieces fit together.