Ostler holds your entire digital life in one place. That is powerful and dangerous in equal measure. This page explains exactly how we protect it. No hand-waving, no “industry-standard encryption.” Specifics, and honest status labels on every claim.
The threat model is different here. A breach of your LinkedIn exposes one slice of your life. A breach of Ostler would expose everything – every relationship, every conversation, every pattern. We built the security around that reality.
Ostler does not connect to any external server. There is no cloud backend, no API endpoint, no telemetry. The databases, the AI models, and the processing pipeline all run on your Mac.
This eliminates the largest, most boring class of attack vector for personal data: server breaches, man-in-the-middle attacks, credential stuffing, insider access at the vendor, and government data requests against the vendor. There is no server to breach. There is no data to request.
You can verify this by disconnecting from the internet. Everything continues to work.
What this is not: a claim that nothing can go wrong. Removing the cloud closes the door an attacker most often walks through, but it does not seal every window. The honest limits – what stays your responsibility – are spelled out in What this doesn’t protect against, below.
There is no password. We took passwords off the table entirely.
On first run, Ostler registers a passkey against your Mac’s Secure Enclave. From that moment on, unlocking Ostler is a Touch ID tap, a Face ID glance, or a double-click on your Apple Watch. The cryptographic proof of identity lives inside your Mac’s hardware security chip. It cannot be exported, phished, or copied to an attacker’s machine.
Creative Machines never sees a password because there is no password to see. We never receive a login token, a session cookie, or a hashed credential. There is nothing for us to lose in a breach because we hold nothing.
Your passkey syncs to your other Apple devices through iCloud Keychain, end-to-end encrypted by Apple. That is how the Ostler iOS companion app will unlock data from the same Hub without a second setup step.
Every Ostler database on disk is encrypted with a 32-byte data-encryption key (DEK). The DEK is generated on your Mac at install time, never leaves your Mac in plaintext, and is wrapped (encrypted) under a key derived from your passkey. Unlocking Ostler means: your biometric unlocks the passkey, the passkey unwraps the DEK, the DEK decrypts the databases. When the app locks, the DEK is wiped from memory.
Ostler auto-locks after a configurable period of inactivity. On lock, the in-memory encryption key is overwritten. A stolen or lost Mac sitting on the attacker’s desk cannot yield plaintext without a live Touch ID / Face ID from you.
There is exactly one fallback: a 12-word recovery phrase generated during setup. You write it on paper. You keep it somewhere safe. You never type it into iCloud, Dropbox, a password manager, or a photo.
The phrase is shown to you once, on a screen that blocks copy-paste, and never stored on disk afterwards. To be specific about what we use from BIP39 and what we don’t: we use its 2048-word English wordlist and its entropy-to-words encoding (128 bits of entropy plus a 4-bit checksum ⇒ 12 words). We do not implement BIP39’s PBKDF2 mnemonic-to-seed step – we treat the entropy as our recovery-key material directly, which is the right choice for a non-wallet system. Ostler is not a cryptocurrency wallet and we do not claim BIP39 wallet compatibility. We use the wordlist because it is publicly audited and ergonomically proven, not because we are interoperating with anything.
If you lose your Mac and your iPhone, and iCloud Keychain has not restored your passkey to a new device, the recovery phrase is how you get back in. It unwraps a second, independent copy of the same DEK.
If you lose the phrase and all your Apple devices and your Time Machine backup simultaneously, your data is gone. By us, by anyone. That is the price of real privacy – the same architecture that prevents us from reading your data prevents us from helping you recover it.
Your data is protected by multiple layers. Each row below shows the current, honest status – not what we intend, what is actually in the build:
| Component | Encryption | Status |
|---|---|---|
| Full disk | macOS FileVault (AES-256-XTS) | Live – installer checks this is enabled |
| SQLite databases | SQLCipher (AES-256) | Live in code – deploys with the installer at launch |
| iOS companion secure store | Realm (AES-256), device-bound key | Live – voice-profile store encrypted on iOS today |
| iOS companion main store | Passkey-derived Realm key (shared with Hub) | In development – cross-platform spec signed off, iOS pairing flow is the next iOS workstream |
| Vector + graph databases | Encrypted APFS volume | In development – scripted volume creation lands in the installer |
| Local audit log | SQLCipher-encrypted, append-only | Live in code – per-entry HMAC integrity chain is a planned upgrade |
| Time Machine backups | Inherits FileVault | Live – via macOS Time Machine encryption |
When the Ostler iOS companion talks to your Mac Hub, the connection is designed to run over TLS with a self-signed certificate generated during install, with the iPhone pinning the certificate’s public key at pairing time so only your Mac can answer.
The cryptographic contract – pairing QR code format, WebAuthn handshake, HMAC-based proof of shared passkey, ten-minute pairing-token expiry – is locked in a normative cross-platform specification that was signed off on 2026-04-23 by both the Hub-side and iOS-side implementers. Every HKDF constant, wire-format byte, and test vector is fixed. Hub-side code-signing is the remaining blocker before iPhone-to-Hub pairing runs end-to-end (see below).
The IT Guy is a planned feature, not yet shipping. When it launches, The IT Guy ($9.99/mo optional add-on) will be the only feature that communicates with an external server. Most people – especially technical users – will never need it. For those who do, it will send system status data only:
It never sends knowledge graph data, contact names, conversation content, email content, calendar details, or file contents. The IT Guy is entirely optional. Ostler works without it.
But how do you know? Every time The IT Guy sends data, a transparent payload panel shows you exactly what is about to be sent – every field, clearly labelled in your own language. You can expand it, read every line, and approve or deny before anything leaves your machine. A persistent log of every payload ever sent is stored locally, browsable any time. We do not ask you to trust us. We show you.
Closing the cloud closes the biggest, most boring class of attack – the kind that exposes a million people at once. It does not mean nothing can ever go wrong. We would rather tell you the limits than let you discover them.
If a piece of malware reaches your Mac through a malicious browser extension, a poisoned download, or a compromised app from outside the App Store, it inherits your user’s ability to talk to localhost. The encryption-at-rest layer protects against physical theft and against your data leaving the device, but it does not isolate Ostler from other software you have given permission to run. Treat your Hub Mac the way you would treat a password manager or a banking app: don’t install random utilities, don’t approve installer prompts you didn’t initiate, and ideally use a Mac that mostly runs Ostler and not much else.
Ostler runs on Docker, Ollama, an LLM model file, a Python runtime, and a small set of Python packages. We don’t write those, we use them. If any of those upstream projects shipped a malicious update tomorrow, fresh installs – ours, yours, every other user’s – would be exposed until the issue was caught. We pin versions, we read changelogs, we keep the dependency surface as small as we can. We are not going to pretend the risk is zero. The same supply-chain caveat applies to any software you ever install, anywhere.
The recovery phrase is the worst-case backdoor. If you write it on a sticky note, take a photo of it, paste it into a cloud notes app, or read it out on a video call, the phrase becomes the attacker’s shortest path. We make it easy to do the right thing – the screen blocks copy-paste, the recovery doc explains the threat – but the final link in the chain is you.
This is the price of a system that holds the keys on your hardware, not ours. We can architect the inside; we can’t architect around bad operational hygiene. The mitigation is honest documentation, not a promise we can keep on your behalf.
We are commissioning an independent security audit from a recognised cybersecurity firm. Firm selection is in progress. The scope covers authentication, data handling, storage encryption, network posture, and dependency analysis. The report will be published here when complete.
We chose a professional audit over relying on community code review because an expert review is more rigorous than hoping someone reads the code. Trust should be verifiable, not assumed. “We promise not to look at your data” is what every cloud company says. “We architecturally cannot look at your data, and here is the auditor’s report proving it” is what we are aiming for.
The architecture is intentionally simple. Passkey-primary auth via Apple’s own frameworks. Standard cryptographic primitives (HKDF-SHA256, AES-KW RFC 3394). Docker containers on localhost. Local Ollama inference. There is very little novel cryptography to get wrong because the primary security mechanism is not having a network connection to begin with.
Authentication
Passkey (WebAuthn Level 2) registered against Apple’s platform authenticator via ASAuthorizationPlatformPublicKeyCredentialProvider, using the PRF extension. Requires macOS 15+ / iOS 17.4+. The PRF output is a pseudorandom value bound to the authenticator, the credential, and the relying-party identifier – non-exportable from the Secure Enclave.
Helper architecture
A small Swift helper binary owns every WebAuthn call and talks to the Python side via one-shot JSON-RPC. Pure AuthenticationServices + Security.framework, no third-party Swift packages.
Relying party
rp_id = creativemachines.ai. Tied to the company domain, not the product name, so a future product rename cannot invalidate existing users’ credentials.
Key derivation
HKDF-SHA256. Domain-separated info strings use the creativemachines/ namespace for the same rebrand-safety reason. No PBKDF2 anywhere in the primary path – the PRF output is already a full-entropy key.
Key wrapping
AES Key Wrap, RFC 3394 unpadded variant. A 32-byte DEK wrapped under a 32-byte KEK produces a 40-byte blob with a built-in integrity check. A wrong KEK fails to unwrap – it does not return garbage plaintext.
Recovery
12-word phrase from the same publicly audited 2048-word English list as BIP39, 128 bits of native entropy plus a checksum word. The 16-byte entropy feeds HKDF-SHA256 with the same shared salt, under a distinct info string, to derive an independent recovery KEK. No PBKDF2 mnemonic-to-seed step – a second KDF over already-full-entropy input adds no security in this threat model. We borrow the wordlist; we do not claim BIP39 wallet compatibility.
At-rest encryption
SQLCipher (AES-256) for the Ostler databases on the Mac Hub. Realm (AES-256) for the iOS companion. Keychain items scoped AccessibleWhenUnlockedThisDeviceOnly, Synchronizable = false – wrapped DEKs never travel in Time Machine or Migration Assistant.
Memory handling
Long-lived session key held as a mutable bytearray and zeroised via ctypes.memset on lock or timeout. Short-lived immutable copies in Python are honestly documented as best-effort only, not claimed as guaranteed scrubbed.
Transport
TLS with a self-signed Ed25519 server certificate generated at install. Public-key pinned by the iOS companion at first pair. No unpinned HTTP. No application-layer fallback channel.
The full cross-platform cryptographic contract between the Mac Hub and the iOS companion, including every constant, test vector, and wire-format byte, is being prepared for the independent auditor.
Transparency means admitting exactly where each piece stands today, with a specific blocker named for anything not yet live:
ASAuthorizationPlatformPublicKeyCredentialProvider + PRF extension via macOS 15 AuthenticationServices. Builds and runs. Keychain operations smoke-tested against real Security.framework on 2026-04-23.ctypes.memset scrub on lock, typed-exception re-unlock callback.register / assert operations – the call silently never completes. Blocked on generating the Creative Machines Developer ID certificate at developer.apple.com and wiring an entitlements file plus an apple-app-site-association document served from creativemachines.ai. This is the single gate between “tested against the mock helper and cross-implementation vectors” and “Touch ID works end-to-end on a fresh Mac.”If you think you have found a security vulnerability in any part of Ostler – the Mac Hub installer, the iOS companion, the passkey helper, the Sparkle update pipeline, or any related infrastructure – please report it to security@ostler.ai.
What we promise in return:
What we ask in return: do not access other users’ data, do not disrupt our services, and do not demand payment as a condition of disclosure. We do not run a paid bug-bounty at launch – if that changes, this page will say so.
PGP: a public key will be posted here at launch for encrypted reports. In the meantime, plain email is fine; Creative Machines Limited’s mail infrastructure is TLS-in-transit.
The security story is the privacy story. Every competitor sends your data to the cloud and promises to protect it. We keep your data on your hardware and prove it cannot leave. That is not a feature. It is the architecture.