Privacy

What stays on your device

• Everything your agents work with. Conversations, documents the agents read, files in your vault, working memory the agents accumulate across sessions — none of it leaves your device unless you explicitly send it somewhere.
• Your at-rest storage. The vault is encrypted with a key derived from your account. We do not have a copy of the key; we cannot decrypt your data, even if compelled.
• Inter-device sync. When your agents move between your devices (Mac ↔ iPhone), they communicate device-to-device over an end-to-end encrypted channel. The cloud relays nothing.
• Your inference. When you bring your own provider key, your machine talks to the provider directly. We never proxy, cache, or see your prompts and responses.

How federation works — the honest version

This is the part most "we respect your privacy" pages get wrong, so we want to be specific.

Alpenglow gets smarter over time, and that improvement comes from learning across all participants — what's called federated learning. We won't pretend we don't have any system-level signals. We do. Here's exactly what those signals are and what they're for:

What the system observes (in aggregate)

• Which models succeed at which kinds of tasks across the user base.
• Which workflow patterns lead to user-confirmed good outcomes vs. abandoned exchanges.
• Which marketplace artifacts get installed, used, and kept; which get removed shortly after install.
• Which integrations break, when, and on which platforms.
• Aggregate performance characteristics — latency, error rates, crash patterns.

What the system does NOT observe

• Your conversation content. The actual text of what you ask your agent, the documents it reads, the responses it generates — none of that is transmitted off your device for federation purposes.
• Your files. Vault contents, attachments, anything stored locally — never transmitted, never observed.
• Your identity tied to your usage. Federation contributions are anonymized at the device level before transmission. We can see that a successful pattern occurred; we cannot see who caused it.
• Cross-account inference. Patterns from your federation contribution don't make their way back as readable content in someone else's session, and vice versa.

Why federation exists

To make Alpenglow get better — for you, and for everyone else using it. Models get smarter when they learn from more variety. Workflows improve when patterns from across many participants surface. Integrations stabilize when failure clusters are visible to the people maintaining them.

The alternative would be: each user runs their own private Alpenglow that learns only from itself, never benefits from anyone else's experience, and never improves except via top-down updates we ship. That's not the product we want to build.

What federation is NOT

• It's not a data sale. We do not sell, license, lease, or otherwise transfer this data to third parties. Not to advertisers. Not to research firms. Not to AI labs (including the providers whose APIs you might use). Not to data brokers. Not to anyone.
• It's not training data for an external model. Federation contributions don't get bundled and sold as a training dataset. They feed back into Alpenglow itself.
• It's not an advertising surface. We don't run ads. Federation isn't there to figure out what to show you to make money from your attention.
• It's not optional in name only. If you opt out of federation, your client genuinely stops sending these signals. Your client still benefits from improvements other participants contribute, but you stop contributing back. You can flip this at any time in Settings.

What this server does see (account-level)

• An anonymized account ID — not your email. When you create an account, you enter an email locally in the app. The app cryptographically hashes (HMACs) that email with a per-account salt before anything leaves your device. The server only ever stores the resulting hash. We can verify "this is the same account that registered earlier"; we cannot recover your email from what we hold, even under legal compulsion. (This is sometimes called a "zero-email" architecture.)
• Display name and license token. A name you choose for the account UI, plus a license token we issue to authenticate API calls.
• Account status. Active, suspended, deleted — operational state, not behavioral.
• Marketplace transactions (post-BETA, when paid items activate). When you buy an artifact, Stripe processes the payment via Stripe Link's agentic rails; we record the purchase against your hashed account ID to grant you access. We don't see your payment method. During BETA, all marketplace items are free and no payments flow.
• Crash reports and performance metrics. Only the aggregate, never tied to specific content. You can opt out.

Access requests vs. accounts: two completely separate systems

It's important these don't get conflated, because we treat them differently and they share nothing:

• Access-request system (BETA waitlist, support, sales). When you fill in the BETA form or email us, you've sent us an email address. That address goes into a small access-management system whose only job is to deliver download access to people we approve. When we grant you access — sending you the install link or invite — we delete your email from that system. No marketing list, no third-party share, no carry-forward. The access system is purpose-built for this single transaction and ephemeral by design.
• Account system. When you install the app and create an account, the macOS client asks for an email and computes account_id_hash = HMAC(email, salt) entirely on your device. Only the hash leaves your machine. The server stores the hash; the email never arrives at our infrastructure in the account flow. Even though it might be the same email you used to request access weeks earlier, the two events are unlinked — the access-request record was already deleted when you got the install link, and the account record is just a hash. We have no way to correlate them.
• After your account exists: the server holds only your hashed ID, your display name, your license token, and account status. We genuinely cannot email you because we genuinely don't have your address.

So if you're worried about a data trail: the BETA access request gives us your email briefly, then the system forgets it. The account itself never sees it. There's no place where "your email" and "your account" are stored together at the same time, because we go out of our way to make sure that pairing never exists.

How product communications reach you (post-account)

Since we don't have your email after account creation, product comms work the other way around: your app subscribes to update channels you choose. When we publish a product update, security advisory, or cohort notice, your app pulls the announcement and surfaces it inside the product. You opt in to channels in Settings. You opt out by unsubscribing locally — we don't have anything to remove on our end because we never had your email.

If you want us to be able to email you (for things like billing receipts post-BETA), there's a separate opt-in where you provide an email through the app and we associate it with your hashed account ID, with your explicit consent. By default, we don't.

What we do NOT do — bright lines

• We do not sell your data — federation contributions, account info, usage patterns, anything — to any third party.
• We do not share your data with advertisers, data brokers, or research firms.
• We do not transfer federation contributions to upstream AI labs as training data.
• We do not relay your agent's calls to AI providers through our servers. When you bring your own API key, your machine talks to the provider directly.
• We do not charge for inference. Ever. (See how we think about inference.)
• We do not maintain the ability to remotely uninstall artifacts you've purchased. Your installed marketplace items are yours; only you (via your agent) can remove them.

Recovery and account deletion

You can wipe your account from inside the app at any time (Settings → Account → Wipe). Account deletion removes the server-side record we hold. We can't remove what's on your devices — that's yours to delete locally. Your federation contributions to date stay aggregated into the system; we don't have a way to identify and pull individual contributions back out (and that's by architectural design — they were anonymized before they ever reached us).

Compliance posture

The architecture is built to default to data minimization. We're working toward formal SOC 2 and GDPR/CCPA documentation as part of post-BETA hardening. If you're an enterprise considering us and need specific attestations, reach out and we'll talk timelines.

Last updated: 2026-05-06 · Beta-period commitment.