Docs · Reference

Security architecture.

The invariants that hold across every install: identity and access, tenancy isolation, the audit chain, encryption and secrets, supply chain, telemetry, and where compliance actually stands today.

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, and every account is held to a minimum-length requirement wherever a password is set or changed.

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.

Administrative operations that do need to reach across organizations, support access, remediation, cross-tenant inspection, live on a separate, narrowly scoped path. The actions available are curated to a specific allow-list, granted for a limited time and a single organization at a time, and every one of them is written to the audit trail before it takes effect, not after.

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.

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 dependency Localization OS ships with is scanned for known vulnerabilities as part of its continuous integration, so a new advisory against something in the install surfaces on its own rather than waiting to be noticed. 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.

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#

Compliance

SOC 2 and ISO 27001: not yet certified.

Formal gap assessments are complete against both standards, the controls behind them are documented, and the remediation roadmap is active. Ask, and you'll get a straight answer about exactly where things stand.