Security architecture.

Identity and access#

Localization OS supports local accounts out of the box: password authentication, secure sessions, and a six-role model, admin, manager, reviewer, linguist, translator, and viewer, with linguist sharing the reviewer rank rather than sitting on a strict ladder. That role model is the same everywhere. The web UI, the REST API, the CLI, and MCP all check the same predicate, so a permission you set in one place holds everywhere a user or an integration can act. Automation gets its own identity: scoped API keys, stored hashed and shown only once at creation, with the scopes they can carry validated at the moment they're minted. Repeated failed logins are met with a lockout, every account is held to a minimum-length requirement wherever a password is set or changed, and password accounts can use two-step sign-in with an authenticator app and recovery codes, which an administrator can require for admins or for everyone. A password policy covers length, character classes, common passwords, history and an optional maximum age, and a session has an absolute limit as well as an idle timeout.

For organizations that run their own identity provider, Localization OS adds single sign-on over SAML 2.0 and OIDC, directory authentication over LDAP, and user lifecycle management over SCIM 2.0, with SAML and SCIM interop-tested against a real identity provider rather than built to spec alone. Every one of these is off by default and turned on deliberately at the host, not through a remote configuration call. A federated sign-in can create a new local account, but it can never take over an existing local-password account under the same name, so directory access and local access stay two separate doors.

Tenancy and confinement#

Where multi-tenant isolation is in use, it fails closed: an operation that can't resolve exactly which organization it belongs to reads as nothing, never as everything. There is no path by which an ambiguous scope quietly falls back to "all rows." Lookups that cross an organization boundary behave the same way for every caller, so probing for another tenant's data returns "not found," not a signal that something is there but forbidden.

There is no cross-tenant web surface and no super-admin account. To change an organization, you sign in to that organization. Creating organizations and moving users between them are host operator actions over the command line, authorized by an operator key held on the server rather than by any account, so cross-organization power requires shell access to the box. Multi-tenant mode is off by default; with it off, the install itself is the tenant boundary.

Audit#

Every mutating action in Localization OS lands in an append-only audit log, and the log is tamper-evident by construction: each row is cryptographically chained to the one before it, so altering a past row breaks every row after it in a way that is detectable. The key that makes the chain verifiable is kept outside the database itself, so having the database alone is never enough to rewrite history convincingly.

The chain also defends against the quieter attack of deleting the end of the log rather than editing the middle: a separate, monitored marker catches truncation, not just tampering. And the audit system's own health cannot be silently switched off to hide a problem. If something goes wrong with the chain itself, that event is recorded too.

The signing key can be rotated on the host. A rotation writes an entry signed by the old key and countersigned by the new one, so history signed before the rotation still verifies and the chain stays one unbroken record. Audit writes are never batched or deferred: each entry is committed, together with its tamper-evidence markers, before the write returns.

Encryption and secrets#

Localization OS supports encryption at rest for uploaded files and for any model-provider API keys you store in it. Full-database encryption is available for SQLite installs, using an optional component. Once a provider key is stored, it is never shown again in full: only enough of it to confirm you're looking at the right one.

Before any text reaches an external translation engine, secret-shaped values are stripped out of what gets logged, and an optional PII-redaction layer can remove personal information from the text itself before it's sent. That redaction layer is available as a fully offline option: when it's on, detection runs locally, with nothing about the content leaving the system to do it.

Supply chain and updates#

Every change passes a pre-merge gate before it reaches the main line. The gate scans every locked dependency, for every install profile, against published vulnerability advisories on every run, so an advisory published yesterday is caught even when the change does not touch dependencies. It also checks the native libraries bundled inside installed packages, which a dependency scanner cannot see, and applies static security rules to the code. A finding blocks the merge unless it is fixed or recorded as an accepted exception with a written reason. Release images for installs Patois Labs hosts are scanned again before they serve traffic. Updates arrive as source, through a private channel you control: you can read every change before it goes anywhere near a production install. Nothing in your environment updates itself. You decide when, and whether, to move to a new version.

AI safeguards#

Model output is checked before it is stored. A refusal, chatter in place of a translation, broken tags or placeholders, or an echo of the prompt scaffolding is quarantined for human review: it is never written as a translation and never reaches translation memory. A refusal signal from Claude, an OpenAI model or a self-hosted engine is treated the same way (Gemini's is not detected yet), and a quality judge that receives a refusal reports itself unavailable rather than passing the segment.

Advanced Workflows keep a transcript of the plan and every tool call so a run can be reviewed. Customer text in that transcript, including source text, translations, evidence and the model's reasoning, is stored only as a fingerprint (a SHA-256 hash and its length), never as readable text. Transcripts written by releases before October 2026 may also keep the first 24 characters of longer texts; they are deleted with the instance or on request.

AI agents and connectors#

An AI agent driving Localization OS over MCP sees only the tools its key's scopes reach, and every call is still checked by the same role rules as the web UI. A paid action needs a plan first, and the confirmation must carry that plan's id, with the same arguments, from the same key, once, within 30 minutes, so text injected into a document or a CMS cannot talk an agent into skipping the plan. Results mark which fields hold outside text (CMS content, segments, vendor error messages) as data, never instructions, and connector results tell the agent that publishing in the other system is a person's decision. A locally run MCP server reads files only from allowed folders, never hidden files, and refuses oversized files before reading them. Sign-in for remote MCP clients over OAuth 2.1 is available and off by default; when an administrator turns it on, PKCE is required, tokens are bound to the MCP server, administration is never grantable, and an OAuth identity cannot create API keys.

Connector credentials are encrypted at rest and never shown again. Once a credential is stored, only an administrator can change the fields that decide what it can reach, such as a Jira query or a Confluence space, and every outbound connector call passes the install's egress guard.

Privacy and erasure#

An administrator can export everything an install holds about a person, or erase them. Erasure scrubs the account and replaces the person's email address with a deleted-user placeholder in every field used to attribute work, such as who created, edited, approved, or was assigned an item. The audit log is the stated exception: its entries are hash-chained so they can prove they were not altered, so entries written before the erasure keep the email address and IP address they recorded. Those entries are visible only to administrators, and the erasure itself is recorded as a new audit entry. When you confirm an erasure to the person, mention this exception.

Telemetry#

None. Localization OS does not phone home. No analytics, no usage beacons, and no license check reaches Patois Labs from a running install. What happens in your environment is not visible to us, by design.

Compliance posture#