Security

Omnox is a beta product built by a very small team. This page says what's real today, what's in progress, and what isn't built yet. That's on purpose, instead of a generic trust page that reads the same for every vendor. If you're evaluating Omnox for your team and something below isn't enough, ask us directly at hello@omnox.ai. We'd rather have that conversation than let a page paper over a gap.

Authentication

• Passwords are hashed with scrypt (salted, per-user), never stored or logged in plain text.
• Sessions are opaque, server-issued tokens stored in an HttpOnly cookie, never in browserlocalStorage. That matters: a script-injection bug elsewhere on the page can't read an HttpOnly cookie the way it could read a token sitting in localStorage, so it closes a real class of session-theft attack, not a theoretical one.
• Login and signup are rate-limited, keyed on both IP address and account, so an attacker can't brute-force one account from many IPs or spray many accounts from one IP without tripping either limit.
• Password reset links are single-use, expire in one hour, and are stored server-side as a hash, never the raw token, so a database read alone can't be turned into an account takeover. Resetting or changing a password revokes other active sessions on that account.
• Multi-factor authentication (passkeys) is on our near-term roadmap, not shipped yet.

Tenant isolation

Every record in the CRM is scoped to a tenant ID, enforced at the data-access layer on every read and write. One customer's data is never visible to another customer's account. Requests without a valid session are rejected outright (HTTP 401) rather than falling back to a shared or default account.

Data in transit and at rest

• All traffic to omnox.ai and crm.omnox.ai is served over TLS via our hosting providers (Vercel, Railway). There is no plain-HTTP path.
• Business data (accounts, contacts, deals, activities) lives in Neon Postgres. Account/auth data (logins, sessions, passkeys, password-reset tokens, the audit log) lives in a separate SQLite store on a persistent Railway volume, confirmed durable across deploys and not the container's ephemeral filesystem. Both providers encrypt data at rest on their end; ask us directly if you need the specifics for your own review.

File uploads

Document ingest (contract/deal extraction) enforces a file-size cap and a file-type allowlist before anything is processed. Uploaded files are processed in memory and sent to our AI provider for extraction; they are not written to disk or made visible to any other tenant.

AI features

Omnox's AI features run on Anthropic's Claude API. See our AI Governance Statement for what data is sent, what isn't, and how AI outputs should (and shouldn't) be relied on.

What we don't have yet

Said plainly, because a vendor security review will ask anyway:

• No SOC 2 or ISO 27001 certification yet.
• No multi-factor authentication yet (on the roadmap).
• No third-party penetration test has been run yet.
• No formal bug bounty program yet.
• No 24/7 on-call security team. This is a small team, best-effort.

None of that is hidden in fine print. It's the honest state of a beta product, and it's why Omnox is priced and positioned the way it is today. If your organization needs one of the above in place before you can use Omnox, tell us. It changes our roadmap priorities, not just our messaging.

Reporting a vulnerability

Found a security issue? Email hello@omnox.ai with details and we'll respond as quickly as we can. Please don't publicly disclose before we've had a chance to fix it. We'll credit you if you'd like once it's resolved.

Changes

This page will change as the product does. We'd rather update it and have it be true than leave a stale claim standing.