Security

Last updated: 11 May 2026

Opmore stores the structured operating knowledge of your company — your sales motion, your playbook, your accumulated context. This page explains where that data lives, who can touch it, and how we keep it honest. If you compare us to other vendors, compare this page to theirs.

Plain rule: we tell you what is actually true today. If a control is on the roadmap, it is on the roadmap, not on this page. If you need something we don’t have yet, email mo@opmore.ioand we’ll tell you straight.

1. Where your data lives

Storage and the running application are in the EU. Some processing steps (LLM inference, email delivery) currently use US-based providers under the EU–US Data Privacy Framework with Standard Contractual Clauses. We track our exposure to non-EU processing on the privacy policy(see the sub-processor table). That list is canonical — if it’s not listed, we don’t share data with it.

2. Access — who can see your data

Inside your account

• You and your invited teammates. Invites are by explicit email. There is no auto-join, no domain-wide auto-share.
• Per-slug access lists.Each playbook (we call them “slugs”) has its own allow-list. A user with access to playbook A does not get access to playbook B unless they are explicitly added.
• Personal layer separation. Pages and notes you mark as personal are not visible to other members of the same playbook, including the playbook owner.

Inside Opmore

• One platform admin. Mohammed Alsaadi (mo@opmore.io) is the only account with cross-customer administrative privileges. He can impersonate a slug for support purposes; every impersonation is recorded in the audit log.
• No support tier with database access. We are small. Mo is the support tier. No outsourced support team touches your data.
• Sub-processors see what they need to do their job. Hostup sees encrypted disk volumes; Turso sees rows; Anthropic sees the text of chat messages you send to the chatbot. None of them see your account password (which is bcrypt-hashed and never leaves our database).

3. Authentication

• Email + password. Passwords are stored as a bcrypt hash. Plaintext passwords are never logged or stored.
• Google sign-in (SSO).If your organisation enforces 2FA on Google accounts, that 2FA inherits to your Opmore sign-in — we never see the second factor, but we will only let you in once Google has verified it. This is the recommended path for organisations that need 2FA today.
• Session cookies. Sessions are signed JWTs stored in an HttpOnly, Secure, SameSite=Lax cookie. Logout server-side revokes the session token (it cannot be replayed even if previously captured).
• Password resets. Single-use, time-limited tokens delivered by email. Resetting a password also invalidates all existing sessions.

We do not yet support native TOTP / authenticator-app 2FA for email-and-password sign-in. If you need 2FA enforced today, use Google sign-in.

4. Audit log — what changed, who did it, when

Every meaningful state change is recorded to an append-only audit log: sign-ins (success and failure), invite sends and acceptances, password resets, playbook content writes, MCP tool calls, sub-processor configuration changes, and platform-admin impersonations. Each entry captures who did it, when, from which IP, and what specifically changed.

Playbook owners can view the audit log for their own playbook in /playbook/admin/audit-log. If you ever wonder whether something was changed by a teammate or by us, this is where you look.

5. AI access via MCP

Opmore exposes your playbook to LLM clients (Claude Desktop, Cursor, Claude Code, the in-product chat) over the Model Context Protocol. A few non-obvious facts about this:

• The LLM is your contract, not ours.When your team’s Claude or ChatGPT reads from your Opmore playbook via MCP, the text it reads is processed under your contract with that LLM provider, in their data-protection regime. Opmore is the structured, audit-able store; the LLM choice is yours. This replaces the common shadow-IT pattern where employees paste deal data into a personal ChatGPT account that the company has no relationship with.
• MCP tokens are scoped per playbook. A token issued for playbook A cannot read playbook B. Tokens can be revoked at any time from /settings/mcp.
• Write tools require explicit consent.An LLM can’t silently modify your playbook through MCP. Write operations are gated by the mcp:write scope, and tools that mutate data are recorded in the audit log.
• Personal-layer pages are isolated per-user. An MCP client authenticated as user X cannot read user Y’s personal layer, even within the same playbook.

6. Encryption

• In transit. All traffic between you and Opmore is TLS 1.2+. HTTP requests are redirected to HTTPS.
• At rest. Turso encrypts data at rest by default on the underlying AWS storage. Our Coolify-managed host uses an encrypted root volume.
• Secrets.API keys for sub-processors and customer integration tokens (Google, HubSpot, Pipedrive, Attio) are stored in the application database. They are not field-level encrypted today — protection comes from database access control and TLS. Field-level envelope encryption is on the roadmap and will be transparent to customers when it ships.

7. Reliability and backups

• Database backups. Turso runs continuous point-in-time backups of the production database. Recovery objective in the worst case is hours, not days.
• Application deploys. Coolify runs each deploy on a new container; rolling back to a prior commit takes a single click and a sub-minute window.
• No formal SLA.We don’t publish a contractual uptime SLA today. Real-world uptime since launch has been >99.9%, but we won’t put a number on a page that we can’t guarantee with proper monitoring SLOs.

8. Vulnerability handling

If you find a security issue, please email mo@opmore.iowith the details. Please don’t open a public GitHub issue for live vulnerabilities. We’ll respond within 48 hours and credit you on this page if you want public acknowledgement.

We do not currently run a paid bug-bounty program. We do appreciate responsible disclosure and will share a coffee-budget thank-you for any real finding.

9. What we do NOT have (yet)

Honesty list. These are things larger vendors will list as certifications. We don’t have them today; we will tell you when we do.

• SOC 2 Type II report. Roadmap item, gated on customer count where the audit cost becomes proportionate.
• ISO 27001 certification.
• HIPAA / BAA. Opmore is not designed for protected health information.
• Custom data-retention contracts beyond what the privacy policy lists.
• Native TOTP 2FA for the email-and-password sign-in path (use Google SSO if you need 2FA).
• Field-level encryption of integration tokens (planned).

10. Questions, due-diligence questionnaires, DPAs

If your security team needs a DPA, a vendor questionnaire, or a SCC-bound contract addendum to onboard us, email mo@opmore.io. Mo will reply with the relevant document or a direct call. We’d rather answer your hard questions than dodge them.