Privacy

• This website sets no cookies, runs no analytics, and does not track you.
• The Alexandria software has no telemetry. It does not phone home, check in, report usage to us, or ping us for updates.
• Your vault lives on your hardware. We do not receive a copy of it, and we cannot read it from where we sit.
• We never use your content to train models.
• Your prompts reach at most three places: your own Keystone hardware, Anthropic, or OpenAI. Never anywhere further. Open-weight models run in your perimeter and involve no egress at all.
• Some things do leave your machine: when you use frontier models, email digests, or a Git backup you configured. 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 Computer, Inc. It covers this website, the Alexandria software we license, and the services that support it: the frontier-model gateway and, where we operate one, a hosted rack.

Where Alexandria runs 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 request a briefing or email us, we receive what you send: your name, your email address, your organization, and whatever you write. We use it to answer you, to prepare a quotation, and to keep a record of the relationship. We do not sell it, rent it, or share it for anyone else’s marketing.

For customers, we also hold ordinary business records: order documentation, contacts, invoices, 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, on storage you own. There is no product database and no vector store holding a shadow copy of your knowledge; search runs over the live files in memory. Chat transcripts are files in the vault too, not app state on someone else’s servers.

The software collects nothing about you for us. There is no analytics library, no crash reporter, no usage beacon, and no update check. The usage counters that exist are per-seat tool-call tallies held in memory, reset when the process restarts, and readable only by you through the product. They contain no note contents and are not transmitted anywhere.

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. None of them runs uninvited, and none of them sends anything to Keystone unless the row says so.

Frontier model calls

When an agent uses a frontier model, for a digest, deep research, ingestion, 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. By default this goes directly to Anthropic with your own key; if you use the Keystone gateway instead, it transits our proxy on the way. Running open-weight models on the server’s own GPUs avoids this entirely.

Your Git backup

The standard install pushes the vault to a private Git repository that you own and control, typically your own GitHub organization. That is a copy of your vault leaving the machine, to a destination you chose. Keystone has no access to it. Installs that need no off-host copy can use local-volume durability instead.

Email digests and inbox capture

Digests and briefs are sent through your own mail server with your own credentials, over an encrypted connection. The mail does not pass through Keystone. Where a hosted brain uses our email relay instead, the relay handles delivery so the brain never holds the 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.

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 list is exhaustive for the current release. The software has no web-search or web-fetch capability of its own, so it cannot silently look something up.

The gateway exists so that Alexandria instances do not have to hold model-provider credentials. 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: work from an Alexandria server reaches your own Keystone hardware, 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 three, 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.

If you would rather nothing left your building at all, run open-weight models, Kimi and GLM among them, on the server’s own GPUs, inside your Keystone environment. That path involves no gateway, no provider, and no egress: the prompt and the answer both stay on your hardware. It is the reason the local GPU plane exists, and it is available for any agent or task you choose to point at it.

Where several brains share one rack, each tenant runs in its own container with its own vault and its own credentials, and the containers are not published to the network: only the router reaches them. A misrouted request lands on the wrong brain and is rejected, rather than being served.

Signing in through the rack’s front door stores what a sign-in needs: registered clients, single-use authorization codes, refresh tokens, and sessions. 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 rack 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 rack in your own perimeter, 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 directly by your server or relayed through our gateway.

OpenAI

Frontier model inference. Named here because it is within the boundary described above and may be routed in future; it is not configured on the gateway today, and no request has been sent to it. Should that change, this line changes with it.

Railway

Hosts the gateway and its database, in Singapore. Holds the accounting ledger and platform logs.

Vercel

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

Postmark

Delivers mail for hosted brains that use the Keystone email relay. Sees the messages it is asked to deliver. Installs that send through their own mail server do not involve it.

Your own Git host, mail server, 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 hardware, under your backup policy, for as long as you keep them.

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 server is.

Alexandria is enterprise equipment sold to organizations. It 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 Computer, Inc., 250 W 55th St, New York, NY 10019, United States.