Security

• Account security: authentication and sessions are handled by Clerk, including session revocation on sign-out. We never store your password.
• Per-user isolation: Postgres row-level security enforces that a session sees only its own user's rows. The API-key path filters every query by the authenticated user id. Plan and entitlement checks are server-side and fail closed: a missing or inactive subscription resolves to free.
• Encryption in transit: all traffic is served over TLS, and a per-request nonce-based Content Security Policy restricts what scripts the app will execute.
• Encryption at rest: provider-side encryption on their storage layer, plus application-level field-level encryption of your personal content. In SophionOS Cloud, note bodies, contact details, and the descriptions and saved links on your areas, goals, projects, tasks, and resources are encrypted with AES-256-GCM before they are written to the database. This is always on for every Cloud account, and the key never reaches the browser. It is not end-to-end encryption: the server holds the key.
• API keys: stored only as cryptographic hashes, shown once at creation, revocable, with optional expiry, per-key labels and scopes, and a read-only default posture for MCP.
• AI controls: a global AI-access switch, a separate write-access switch, per-key write modes, and activity metadata you can review. Revoking a key rejects subsequent requests immediately.
• Logging and visibility: security and access logs, retained for at least one year, so that unauthorised access can be detected, investigated, and remediated.
• Backups and recovery: Cloud takes provider-backed backups. They are not zero-knowledge: the operator holds the encryption key, so the contents of a backup are readable by us.
• Operator access: production credentials are held by the founder/operator and used for incident response, a support escalation you initiate, or legal process. Support will never ask for raw API keys, passwords, session tokens, or a full dump of your notes.

Where the DPDP Rules, 2025 apply, Rule 6 requires a Data Fiduciary to take, at minimum, the following measures. Where they apply to you, we meet them as follows:

When we become aware of a personal data breach we contain it first, then notify: we do not wait for the investigation to finish. We intimate to the Data Protection Board of India under Rule 7 of the DPDP Rules, 2025, and to each affected Data Principal, without delay. Notices tell you what happened, what data was involved, what we have done, what you should do, and how to reach a person who can answer questions. The Privacy Policy sets out our breach commitments in full.

• Use a unique password on the identity provider, and turn on multi-factor authentication there.
• Treat an API key as your full identity on the API surface it reaches. Give keys short expiries, use read-only where possible, and revoke keys you no longer use.
• Understand that once you connect an AI client, that client and its provider process what they receive under their own terms.

• That we cannot read your data: SophionOS Cloud holds the encryption key server-side, so our service role and the operator can read your content. We do not operate a zero-knowledge architecture.
• Military-grade security, or zero risk.
• That external AI providers never receive data after you connect a client: they do, because that is what connecting a client does.
• End-to-end encryption. We do not offer it, and we will not describe the service as end-to-end encrypted. Field-level encryption protects your content at rest in our database, but the server holds the key, so search, dashboards, and the email briefs you enable can read your content.
• A formal third-party security audit or a certification such as SOC 2 or ISO 27001. We have none today, and we will not describe ourselves as audited until one exists.

Report vulnerabilities through responsible disclosure.

This page is product documentation, not legal counsel.

Privacy Policy · Terms · Subprocessors · Data & AI · Responsible Disclosure