Keystone Computer
Security
Alexandria exists because the alternative is sending an organization’s memory to someone else’s servers. This page describes how the product is built to avoid that, what protects the services around it, and what we do not yet claim.
Last updated 26 July 2026
1.Principles
- The perimeter is the boundary
- The server stands in your building. What your agents read, write, and remember is on hardware you own, and stays there by default rather than by policy.
- Isolation in the operating system, not in model behavior
- Where brains have to be kept apart, we separate them with process and container boundaries, not with instructions to a model. A prompt cannot be talked out of a kernel boundary.
- Allowlist, not blocklist
- Exposed surfaces name what is permitted and refuse everything else, so a new route added by a future dependency upgrade is unreachable until someone deliberately allows it.
- Fail closed
- Where a control depends on configuration, we write it so that missing configuration denies access rather than granting it, and we test that it does.
2.The server, in your perimeter
An Alexandria vault is ordinary files, Markdown and its Git history, on storage you own. There is no Keystone cloud holding a copy of it. The software has no telemetry, no analytics, no crash reporting, and no license call-home: if Keystone disappeared tomorrow, the machine and everything on it would keep working.
Models can run entirely on the server’s own GPUs: open-weight models such as Kimi and GLM, served in your perimeter. Configured that way, agent work involves no outbound inference traffic at all, which is the strongest posture available and the reason the local GPU plane exists. Where you choose frontier models instead, that traffic leaves through the gateway described below, and the choice is made per agent and per task rather than once for the whole system.
Either way there is a hard ceiling on where work can go: your own Keystone hardware, Anthropic, or OpenAI. Nothing routes past those three, and adding a fourth would require changing the gateway configuration, this page, and the Privacy notice.
Access to a brain is by bearer credential, and it is whole-brain: a seat that can reach a vault can reach that vault. We tried per-area walls inside a single brain and removed them, because a boundary that a model could be talked across was providing reassurance rather than security. Separation now comes from giving each principal their own brain. A seat can still be issued read-only.
Every write is committed to the vault’s Git history, so what an agent changed, and when, is recoverable and auditable after the fact. File access is confined to the vault: path traversal and symlink escapes are refused, and the configuration file holding other seats’ credentials is unreadable through the tool surface.
3.Multi-tenant racks
Where one rack hosts several brains, separate executives or departments inside one institution, each tenant gets its own container, with its own vault, its own process, and its own resource caps. The single-vault server runs unchanged inside it.
This is a deliberate rejection of the easier design. Serving many vaults from one process would make a single routing or permissions bug enough to cross between tenants, with no operating-system boundary to catch it. Requests are routed to a container by hostname and authenticated by the tenant’s own bearer seat, with an OAuth front door in front for clients that sign in interactively.
4.The frontier-model gateway
When Alexandria routes work to frontier models, it reaches them through the Keystone gateway rather than holding provider credentials itself. That indirection is what makes keys revocable, spend attributable, and access removable without touching a machine in the field.
- No public control plane
- The inference process has no public address. A separate edge proxy holds the public hostname and forwards only the handful of exact paths a customer actually calls; every other path is refused and never reaches the origin. Administrative routes are not reachable from the internet at all: key minting, spend history, tenancy.
- Encrypted in transit
- Traffic between you and the gateway travels over TLS, with strict transport security set and certificates renewed automatically. Traffic onward to the model provider is likewise over TLS.
- Request bodies are not written to our logs
- Verbose logging is off and no third-party logging or observability sink is configured, so prompts and completions are not written to our platform logs. Credentials are kept out of access logs. What our logs hold is request metadata: path, status, timing, and the usual transport details.
- Metered by key, not by identity
- The gateway records accounting rows so usage can be billed and budgets enforced: which key, which model, how many tokens, when. That ledger is what lets us cap and revoke a key.
- Provider credentials encrypted at rest
- Upstream provider keys are stored encrypted in the gateway’s database, under a salt set before first boot.
- Bounded, revocable keys
- Each customer holds a virtual key with its own budget and rate limits, not a provider key. A key can be capped, rotated, or revoked immediately, and a leaked one cannot outlive its revocation.
5.How we operate
Administrative credentials are held in a password manager, not in source control or in shared documents. Secrets are supplied to services as environment configuration, and rotating one is a configuration change that invalidates existing sessions.
The same rule is enforced in the product: a vault’s configuration file names the secrets it needs but never contains their values, and configuration that tries to inline a value is rejected rather than accepted. Values live in a file outside the vault with restrictive permissions, so a vault that syncs to a Git repository cannot carry credentials into it. The local configuration dashboard binds to the loopback interface only, and shows which secrets are set without ever displaying them.
Security-relevant surfaces are re-verified after dependency upgrades rather than assumed to have survived them, because an upgrade can introduce routes that a previous review never saw. The gateway’s posture, including its known limits, is documented internally and kept current with what is actually deployed.
6.What we do not claim
Keystone is a small company building infrastructure for serious institutions. The honest boundary matters more than the impressive one, so:
- We do not hold SOC 2, ISO 27001, or any comparable third-party certification today. If your procurement process requires one, tell us where it sits in your timeline and we will tell you where it sits in ours.
- We have not commissioned an independent penetration test of the hosted services, and we will not imply otherwise.
- We do not run a paid bug bounty program.
- We do not encrypt vault contents at the application layer. A vault is plaintext Markdown in a Git repository, protected by the disk encryption and access controls of the machine it sits on. Claiming otherwise would be the easiest sentence on this page to write and the least true.
- Any credential a customer holds, including a license file, is live until it is revoked. Treat it as you would a password.
- Security of the building the server stands in, the network it sits on, and the accounts of the people who use it, is yours. We can only defend the machine we ship.
7.Reporting a vulnerability
If you have found a security problem in Alexandria, in this website, or in the Keystone gateway, please report it to hello@keystone.computer. Please include enough detail to reproduce it: the affected component, the steps, and what you observed. If you would like an encrypted channel, ask and we will arrange one.
We aim to acknowledge a report within five business days, keep you updated while we investigate, and credit you when a fix ships, unless you would rather stay anonymous. Please give us a reasonable opportunity to fix an issue before disclosing it publicly.
We will not pursue legal action over good-faith research that respects these boundaries: work only against systems and accounts that are your own, do not access, modify, or retain anyone else’s data, do not degrade a service for others, and stop as soon as you have demonstrated the problem.
8.If something goes wrong
If we discover a security incident affecting your data or your systems, we will tell you without undue delay, describe what we know and what we do not yet know, say what we are doing about it, and follow up with what we found. We would rather send an early notice that turns out to be minor than a late one that was not.
Related: Privacy · Terms · License Agreement