Privacy

• This website sets no cookies, runs no analytics, and does not track you.
• The Alexandria software has no telemetry: no analytics, no crash reporting, no usage beacon. What it does send us is a daily check for a new version and a short census record about itself, neither of which carries a word of your vault; both are listed below.
• Your vault lives on your own Mac. We do not receive a copy of it, and we cannot read it from where we sit; a Library we host for you is the one exception, and the section on hosted Libraries says exactly what that means.
• We never use your content to train models.
• Your prompts reach at most two places: Anthropic or OpenAI, the provider behind the app you already use. Never anywhere further.
• Some things do leave your machine: when the Library uses a model, sends a digest, syncs to a Git repository you connected, or reads a feed you asked for. Exactly what, and to whom, is listed below.

The rest of this page is the detail behind those points. If anything here is unclear or seems wrong, please tell us. A privacy notice that does not match the code is worse than none.

This notice is published by Keystone Context Systems, Inc. It covers this website, the Alexandria software, and the services that support it: the relay that carries mail and messages between Libraries, the frontier-model gateway, and any Library we host for you.

Whether Alexandria runs on your own Mac or inside your organization, you are the controller of the information in it and we are not. This notice tells you how the product behaves so you can meet your own obligations; it does not put us in charge of your data.

There are no cookies, no analytics, no tag managers, no advertising pixels, and no third-party scripts on this site. Nothing is stored in your browser and nothing follows you when you leave.

The site is hosted on Vercel, which keeps standard server logs for operational and security purposes: IP address, request time, page requested, user agent. We do not build profiles from them and we do not link them to anyone.

The status page shows whether the gateway is up. It is generated on our side, so viewing it does not send anything about you anywhere.

If you email us, we receive what you send: your name, your email address, and whatever you write. We use it to answer you and to keep a record of the conversation. We do not sell it, rent it, or share it for anyone else’s marketing.

Where we license Alexandria to an organization, issue a Keystone key, or host a Library for you, we also hold ordinary business records: contacts, invoices, the licence files we issued, support correspondence. We keep them for as long as the relationship lasts and for as long afterwards as tax and contract law require.

An Alexandria vault is plain Markdown files and their Git history, in a folder on your own Mac. There is no product database and no vector store holding a shadow copy of your knowledge; search runs over the live files in memory. The conversation you have with it happens in your own Claude or ChatGPT app, under that provider’s terms, not on a server of ours.

The software collects nothing about you for us. There is no analytics library, no crash reporter and no usage beacon. Once a day it asks this site whether a newer version exists, a plain fetch of a small version file that carries nothing about you beyond what any web request carries, and it announces itself to the relay’s census, described below. Where a Library is served to other devices, the per-seat tool-call tallies it keeps are held in memory, reset when the process restarts, readable only by you, and contain no note contents.

One consequence worth stating: because the software does not call home, we cannot tell you what is in your vault, recover it for you, or confirm whether something happened on your machine. That is the trade, and it is the right way round.

Alexandria is private by default, not by absolute. It is a working system, and some features are network features. Each of these is triggered by something you configure or ask for, or is a routine the row names. None of them sends a word of your vault to Keystone unless the row says so.

Frontier model calls

When the Library uses a model, for a digest, deep research, filing or triage, the relevant content goes to the model provider. That means real vault material: note text, task lists, the body of an email being filed. In the Code tab that is the provider behind the app you already use, Anthropic or OpenAI, under your own subscription. Where the Library’s own scripts call a model, they go directly to Anthropic with your own key, or through the Keystone gateway if we issued you one, which relays them on the way.

Your Git backup, if you connect one

A Library keeps its own Git history on the Mac and needs no account to do so. If you ask it to sync to GitHub, it creates a private repository you own and keeps the vault pushed there: a copy of your vault leaving the machine, to a destination you chose, and only your files, never the software. Keystone has no access to it.

Email digests and inbox capture

Where you connect a mailbox, digests and briefs are sent through your own mail provider with your own credentials, over an encrypted connection, and the mail does not pass through Keystone. Where a Library sends through the Keystone email gateway instead, the gateway handles delivery so the Library never holds a mail provider’s key, and it sees the message it is asked to send.

Outbound recipients are allowlisted in code

The email tool refuses to send to any address that is not already in your configuration: your own addresses, your team, your named peers. This is enforced by the software, not by asking a model nicely. Inbound capture is restricted to the owner's own addresses, and requires sender authentication to pass before anything is accepted.

Mail to your Library’s address

A Library can be given an address of its own at setup. A message forwarded to it is checked at the door by the Keystone email gateway: the sender has to be on your list, and their mail provider has to vouch for the message. The gateway sees the message it is asked to check, seals it to your Library’s key, and hands it to the relay, which holds only the sealed copy until your Library collects it. Nothing is filed until you review it.

The relay, between Libraries

When two Libraries are paired, what one pushes to the other travels through the relay at relay.keystone.computer as a sealed envelope only the receiving Library can open. The relay sees which Library sent to which, when, and how large the envelope was; it cannot read the contents. A Library also announces itself to the relay’s census, at setup, after an update, and while it is served: a short record under its own identity fingerprint, giving its engine version, the platform it runs on, what kind of Library it is and how it is served, how many peers it has, and the versions of the software underneath it. Never a note, never your name. You can switch the announcement off in the Library’s configuration.

The news read, if you ask for one

When you ask for a news briefing, the Library fetches public feeds from the newsrooms in its source list, and when you hand it a link it fetches that page. Those are plain requests to those sites, carrying nothing about you beyond what any web request carries. Nothing from the vault goes with them.

The clock

The Library checks the time against public time servers (Cloudflare, Google, Apple and the NTP pool) so that the dates it writes are right even when the Mac’s clock is not. A time query carries no identifier and no content.

Weather, if you enable it

A digest weather line fetches from a public forecast service using coordinates and a timezone. No key, no account, no identifier: nothing that says who is asking.

Calendar, if you connect it

If you supply credentials, the digest reads your calendar with read-only scope to summarize the day.

Object storage, if you configure it

Optional backup and file-upload backends write to an S3-compatible bucket of your choosing.

That is the list for the current release, re-read against the software this site serves whenever it changes. What a row sends is what it says it sends.

The gateway exists so that a Library we issue a key to does not have to hold model-provider credentials of its own. It runs on Railway infrastructure in Singapore with a managed Postgres database, and it relays requests to a frontier model provider. Today that is Anthropic, and only Anthropic. No other provider is configured.

There is a ceiling on this, and it is the commitment worth reading twice: model work from a Library reaches Anthropic or OpenAI, and nowhere further. No data broker, no advertising network, no analytics vendor, no other model provider. If we ever add a destination beyond those two, it appears in this notice and on the status page before it carries a single request.

Requests pass through it. Verbose logging is off and no third-party logging or observability service is connected, so prompts and completions are not written to our platform logs. What the gateway keeps is the accounting record it needs to bill and to enforce budgets: which key made the request, which model answered, token counts, cost, and when. Those rows are what let us cap a key and revoke it.

Anthropic’s own terms govern what it does with content submitted to its API; its commercial terms state that it does not train models on inputs or outputs submitted through it. We do not train models on your content, and we have no model of our own to train it on.

Where we host Libraries, several share one host, and each runs in its own container with its own vault and its own credentials; the containers are not published to the network, and only the router reaches them. A misrouted request lands on the wrong Library and is rejected, rather than being served.

Signing in through the host’s front door stores what a sign-in needs: registered clients, single-use authorization codes, refresh tokens, and sessions, with the tokens hashed at rest. Access tokens are deliberately not stored. Sign-in requests are logged with the query string stripped, so credentials do not reach the log.

The honest limit: on a host that Keystone operates, isolation is a container boundary, not cryptography. Whoever runs the host could in principle reach a tenant’s files. We do not, and our tooling is not built to. What it exposes to an operator is tenant names, tool-call counts, and infrastructure logs. But we will not tell you it is impossible, because on that deployment it is not. If that matters to your threat model, run the Library on your own Mac, which is what the product is designed for.

The services we rely on to run Keystone, and what each one can see:

Anthropic

Frontier model inference, and the only model provider routed today. Sees the content of requests routed to it, whether sent by the Claude app on your Mac, directly by your Library with your own key, or relayed through our gateway.

OpenAI

Frontier model inference. Sees the content of requests the ChatGPT app on your Mac sends it, if that is the app you run the Library in. It is not configured on the gateway today, and the gateway has sent no request to it. Should that change, this line changes with it.

Railway

Hosts the gateway and its database, in Singapore, and the relay and the email gateway. Holds the accounting ledger, the relay’s sealed envelopes and census, and platform logs.

Vercel

Hosts this website and serves the domain. Sees ordinary web server logs.

Postmark

Delivers mail for Libraries that send through the Keystone email gateway. Sees the messages it is asked to deliver. A Library that sends through your own mail provider does not involve it.

Your own Git host, mail provider, calendar, and object storage are yours, not ours. We never receive credentials for them, and they are not on this list because we are not the ones using them.

Business correspondence and customer records are kept for the length of the relationship and the period afterwards that tax, accounting, and contract law require.

Gateway accounting rows are kept so that usage can be billed and reconciled. We have not yet set a fixed deletion schedule for them, and we would rather say that than publish a retention period we do not actually enforce. If you need one written into a contract, ask and we will agree it.

Vault contents are not ours to retain. They sit on your Mac, under your backup policy, for as long as you keep them; a hosted Library’s sit on the volume we run for it, for as long as you keep the Library.

You can ask what personal information we hold about you, ask us to correct it, ask for a copy, or ask us to delete it. Write to us and we will respond within a month, and sooner where we can. We will not charge you for it or make you justify the request.

Depending on where you live, in the EEA, the UK, or certain US states, you may have additional rights, including to object to processing or to complain to a data protection authority. If you are in the EEA or the UK and want to escalate, you are entitled to go to your national regulator, though we would appreciate the chance to sort it out first.

We do not sell personal information, we do not share it for cross-context behavioral advertising, and we make no automated decisions about you that produce legal or similarly significant effects.

Keystone operates from New York and Manila, and the gateway runs in Singapore. So business information you send us, and gateway accounting data, may be processed in the United States, the Philippines, and Singapore. Where we move personal information out of the EEA or the UK, we rely on the appropriate safeguards for that transfer, and we will describe them on request.

Vault contents do not move between countries because of us. They stay where your Mac is, or, for a hosted Library, where we run it.

Alexandria is not directed at children, and we do not knowingly collect information from them.

When the product changes, this notice changes with it. That is the point of writing it from the code rather than from a template. The current version is always at this address, with the date it was last updated. We will give notice of material changes rather than editing quietly.

Privacy questions, requests about your information, and anything you think this page gets wrong: hello@keystone.computer, or by post to Keystone Context Systems, Inc., 250 W 55th St, New York, NY 10019, United States.