Security & Privacy

• HttpOnly cookie sessions: Your session token lives in a Secure, HttpOnly cookie set by the auth endpoints. Page JavaScript cannot read it, so an XSS bug cannot exfiltrate your session.
• Two-factor authentication: Enable TOTP (Google Authenticator, Authy, 1Password and similar) under Settings › 2FA. We strongly recommend it for anyone with owner or admin rights.
• Session revocation: Logging out clears the session cookie and revokes the session server-side, so a copied token stops working. Review and revoke sessions from Settings › Security.
• Enterprise SSO on Scale: OIDC sign-in with SCIM 2.0 directory provisioning, so joiners and leavers are handled by your identity provider. Configure it under Settings › SSO.
• Tokens for machines, not browsers: The CLI, SDK and API authenticate with a bearer personal access token rather than the browser cookie. Tokens are scoped to your account and can be revoked individually.

• Every read is team-scoped. Queries resolve through the caller's team membership, so data in one workspace is not reachable from another — including through search, the memory graph and the AI agent's retrieval.
• Roles are team-scoped, not global. Being an admin of one team grants nothing in another. See Roles & Permissions.
• Guests are read-only server-side. The refusal lives in the API, so a read-only stakeholder cannot write through a different client or by asking the AI agent to do it.
• A trashed project closes everything under it. While a project sits in the Trash, its work items deny access rather than remaining quietly reachable by id.

Publishing a project to the web is the only place Lithora serves workspace data with no session, so that path is deliberately narrow:

• Unguessable token. The link carries a high-entropy random token; project ids are never exposed in it.
• Explicit field allow-list. The public view returns only project name, description, status and dates, plus each work item's title, status, priority, due date and tags. Member emails, assignee identities and internal ids are never included — there is nothing in the response to replay against an authenticated endpoint.
• Revocation is immediate. A revoked link stops resolving at once, and it returns the same “not found” as an unknown token so tokens cannot be enumerated.
• Optional expiry. Set one at publish time and the link stops working on its own.

Full walkthrough: Guests & sharing.

Consequential actions are recorded with who did them and when — including sharing and unsharing a project, restoring and purging from the Trash, membership and role changes, and every action the AI agent executes after you approve it.

• • Sign-in and sign-out events
• • Invitations, joins and removals
• • Role and permission changes
• • AI actions executed after approval
• • Share links published and revoked
• • Deletes, restores and permanent purges
• • File uploads and downloads
• • Integration connections and disconnections

• Approval gate: The agent plans first and executes only after you approve the specific actions. Nothing is written to your workspace behind your back.
• Scoped context: Retrieval is confined to your own team's data, and deleted work is dropped from the index so it cannot be surfaced or cited.
• No training on your data: Your workspace content is not used to train models.
• Auditable: Every executed action is written to the audit trail with the approving user.

• Hosting: Runs on AWS. All traffic is served over TLS, and stored objects and database volumes are encrypted at rest by the provider.
• Backups: The database is dumped on a nightly schedule and shipped to object storage, so a restore point exists independently of the running instance.
• Status: Live availability is published at status.lithora.app. Formal uptime SLAs are negotiated as part of an Enterprise agreement.
• Support access: Lithora staff do not browse your workspace content. Support access requires your explicit, time-bound permission and is recorded.