Security

Every account-data table has Row Level Security enabled in our Postgres database. Your account can read only its own rows (plus the organization records described below, if you join an organization) and cannot write to the API-key table directly: keys are created and revoked only through database functions that check who is asking and read your plan's key limit from your subscription, not from the request. Our server-side routes use a privileged database key to check API keys and record usage; that key is never sent to your browser.

If you join an organization, its members can see your email, your role, when you joined, whether you are still a member, when you last used Locus's hosted features and which Locus version you ran. Its admins can also see its invites and audit log, and can revoke your Locus API keys. Nobody in the organization can see your files or searches, because Locus doesn't store them. As the operator, we can read account records in the database for support and billing.

API keys are stored as hashes, never in plaintext. You can revoke your own keys from the dashboard at any time, with no admin approval needed. The embedding relay, the remote-connection relay and the account-status check look the key up on every request with no caching, so a revoked key is refused on its next request. One exception: a relay token already created from the key stays valid for up to ten minutes. A relay token is an account-level session, not only a connection for your computer: for its lifetime it can act as your account. Our database refuses relay tokens for creating or revoking API keys; they are not otherwise limited to the relay yet. Whether a relay connection that is already open is closed the moment its token expires is not yet verified.

Anyone who holds your Locus API key can search and read your indexed files through the relay while your computer is serving, take over as your relay computer, spend your managed-embedding budget, and act as your account for up to ten minutes with each relay token they get from it. Keep it secret. If it leaks, revoke it from the dashboard, then check your key list again after ten minutes and revoke any key you did not create.

The local engine — the part that actually holds your indexed chunk text and vectors — stores its data in ~/.locus (or a directory you configure via LOCUS_DATA_DIR). That directory is created with 0700 permissions: owner-only read, write, and execute. Other local OS accounts on the same machine can't read it. This limits access on a shared machine; it does not encrypt the data at rest — full-disk encryption (standard on most modern laptops) is the real first line of defense for a lost or stolen device, and Locus relies on that rather than re-implementing its own at-rest encryption.

Locus also refuses to follow symlinks during indexing or file reads, so a symlink placed inside a folder you point Locus at can't be used to reach content outside that folder. locus_read_file (the MCP tool an AI assistant calls) can only read a path already present in your local index — never arbitrary filesystem access.

We do not claim that multi-factor authentication is enforced on every account that controls our production infrastructure.

We use SOC 2's Trust Service Criteria as a checklist; no audit has been performed. We have not undergone a SOC 2 audit, and we don't claim to be SOC 2 compliant or certified — a report like that is issued by a licensed CPA firm after a paid, independent audit, and no such audit has happened. The same honesty applies to any other framework: we don't hold ISO 27001 certification, and we don't claim GDPR or any other regime's "compliant" status as a blanket claim — see /privacy for exactly what does and doesn't apply, and where our own open compliance items are flagged rather than glossed over.

• No formal penetration test has been run.
• No SOC 2 report or ISO 27001 certification exists today.
• No dedicated security team or on-call rotation — one person handles security operations today, and that's disclosed here rather than implied otherwise.
• No log-retention or SIEM tooling of our own — visibility into what happened relies on each vendor's own dashboard/audit log, not a centralized view.
• No formal, tested incident-response drill has ever been run.

If you find a security issue in Locus — the local engine, the MCP server, or locus-web — we want to know. Email yonilev2003@gmail.com with what you found, the steps to reproduce it, and its potential impact if you can. There is no published response time.

There is no bug-bounty program.