Security overview

Overview

Ottili ONE is built platform-first: security is not a bolt-on layer but part of the shared control plane. Every company works in its own clearly bounded tenant context, and sensitive actions never run without the right permission or a human approval. This article gives a high-level view of the security architecture — from tenant isolation and authentication to reporting a vulnerability.

Deeper articles on each area are listed under [Related articles](#related-articles).

Company-scoped tenant isolation

Ottili ONE is company-scoped. Every business record belongs to exactly one verified company_id. Cross-company access is never inferred from a default, a first membership, or request input.

• Fail-closed enforcement:* the shared assert_same_company() primitive rejects any request with no or mismatched company context. A caller-supplied company_id is never trusted.
• Database row-level security:* PostgreSQL filters every platform row by the verified company_id. The runtime default state is deny (deny-by-default).
• A single tenant boundary:* PlatformContext is the one tenant boundary. With no verified company, validate(require_company=True) returns an HTTP 403.
• Enforced across the platform:* the Unified API middleware extracts the verified company_id per request and installs the RLS hook so every transaction stays company-scoped. The realtime bus uses scoped channels (co.{company_id}) and denies access on missing context or mismatch.
• One permission engine:* there is exactly one permission engine with deny-by-default. Unknown role, unknown permission, missing company, or cross-tenant access is denied — with no hidden admin shortcut and no wildcard (*) grant.
• Company-scoped search:* global search indexes and returns only the requesting company's documents. This depends on the indexing job honoring company_id (qualified).

Identity and authentication (Ottili Auth)

Identity is provided by Ottili Auth*. The core mechanisms, each evidenced in the source code:

• Passwords:* user passwords are hashed with Argon2id*. Ottili ONE never stores plaintext passwords.
• JWT access tokens:* Ottili ONE issues signed JWT access tokens (HS256*) and verifies them on every authenticated request.
• Refresh-token rotation:* refresh tokens rotate on a time-based policy; reuse of an already-rotated token is detected and rejected.
• Second factor:* where enabled, Passkeys (WebAuthn)* and Multi-Factor Authentication (TOTP)* add a second verification step.
• Sign-in:* you can sign in with email and password, Google, Microsoft, or a connected Ottili SSO product.
• Sessions:* sessions expire after an idle period and an absolute maximum lifetime; both are configurable by your organization.

For step-by-step actions (create account, enable passkeys, reset password), see [Account and login](/docs/account-and-login) and [Account & data security](/docs/account-and-data-security).

Access control and permissions

Access in Ottili ONE is explicit: people and automations reach only what you have permitted.

• Roles and permissions:* Owner, Admin, Manager, Employee and Viewer determine who can see and do what. Sensitive operations check the role before they run.
• Approval queue:* certain actions are released through the Approval Queue — including AI-assisted actions, which run only with a human approval.
• Shared permissions and entitlements:* modules, features and AI reach are governed by one shared permission model.
• Ottili Coder:* the Coder environment follows the same identity, secrets and audit rules.

Learn more in [Roles and permissions](/docs/roles-and-permissions), [Shared permissions and entitlements](/docs/shared-permissions-and-entitlements), [Approval queue](/docs/approval-queue) and [Company, team & permissions](/docs/company-and-team). The administration surface is covered in [Navigate the Ottili Console](/docs/navigate-ottili-console) and [Coder security](/docs/coder-security).

Data protection and encryption

• At rest (backups):* Ottili ONE can encrypt backups at rest with AES-256-GCM* when backup encryption is enabled and a passphrase is configured. This is optional / configuration-dependent (qualified).
• In transit:* service-to-service traffic verifies TLS/SSL certificates; outbound email uses STARTTLS when enabled. Public website traffic is protected by the platform gateway (Caddy).
• Passwords and tokens:* see [Account & data security](/docs/account-and-data-security) — Argon2id and HS256 are verified.

Secrets management

• Environment-backed only:* all configuration and integration secrets (JWT, session, API keys, webhooks, payments) are injected via environment variables and validated at startup with a pydantic settings model. No secret is hardcoded in source.
• JWT signing secret from the environment:* access and refresh tokens are signed and verified with a secret loaded from the environment.
• No exposure on public endpoints:* health and status endpoints expose only the presence of a configuration, never the secret value itself.
• Secret-field redaction:* fields such as password, token, api_key, client_secret, private_key and encryption_key are masked during content sanitization.
• Never committed:* secret material lives in local keys/*.env files or the deployment secret store and is excluded from version control; only .env.example templates and the secrets-management code are tracked.

Audit and accountability

Important actions are logged and made visible through observability. Together with deny-by-default access control and company-scoped isolation, this produces an auditable trail across every module (Business Hub, LD3, Ottili Files, Flows, Coder).

Incident response and vulnerability reporting

Ottili takes reported vulnerabilities and incidents seriously. Report a vulnerability responsibly through the disclosure channel on the [Security overview](/security) page or to security@ottili.one*.

• Acknowledgment:* Ottili acknowledges a well-formed report within 72 hours*.
• Severity model:* Critical, High, Medium, Low — each with defined response targets and update cadence.
• Process:* detection & triage → containment → communication (status page + direct contact) → resolution & post-incident review.
• Coordinated disclosure:* Ottili coordinates disclosure with reporters, names no individuals, and does not pursue researchers acting in good faith.

Details and the report scope are in [Account & data security](/docs/account-and-data-security).

Certifications and compliance

Ottili ONE is built for data protection (GDPR). The current status, maintained in the Product Truth registry:

• GDPR (EU data protection):* Referenced — Ottili ONE is built for GDPR (data-subject rights, lawful bases, retention limits, sub-processor transparency).
• SOC 2 Type II:* Planned — no attestation completed yet; we do not claim SOC 2 certification.
• ISO/IEC 27001:* Planned — alignment is planned; Ottili is not yet certified.
• ISO/IEC 27017:* Not held — we do not claim this certification.

Claims that are not yet verified are never presented as certified.

Status terms

Ottili ONE clearly distinguishes Live, Beta, Private Beta, In Development, Planned and Concept. What these terms mean is explained in [Understand feature status labels](/docs/understand-feature-status-labels).

Related articles

• [Account & data security](/docs/account-and-data-security) — authentication, sessions, isolation, audit, reporting vulnerabilities.
• [Roles and permissions](/docs/roles-and-permissions) — who can do what.
• [Shared permissions and entitlements](/docs/shared-permissions-and-entitlements) — the cross-cutting permission model.
• [Approval queue](/docs/approval-queue) — human approval for sensitive actions.
• [Company, team & permissions](/docs/company-and-team) — how roles and access work.
• [Navigate the Ottili Console](/docs/navigate-ottili-console) — where to find settings and administration.
• [Coder security](/docs/coder-security) — identity, secrets, isolation and audit for Ottili Coder.
• [Understand feature status labels](/docs/understand-feature-status-labels) — what the status terms mean.