OmniInbox AI handles customer conversations, which are among the most sensitive records a business keeps. This page explains the security practices we actually implement today.
We describe controls that are in place. Where something is planned rather than implemented, we say so explicitly instead of implying a certification or capability we do not have.
1. Platform architecture
OmniInbox AI runs on managed cloud infrastructure with a managed PostgreSQL database and a serverless application runtime. We do not operate physical servers ourselves, and infrastructure-level security is handled by our infrastructure providers.
All application traffic is served over HTTPS with TLS. Sensitive operations run server-side rather than in the browser.
2. Workspace data isolation
Every record that belongs to a business is scoped to a workspace. Data access is enforced in the database itself using row-level security policies, not only in application code.
In practice this means:
- Members can only read and write data belonging to workspaces they are a member of.
- Policies are applied per table, including conversations, messages, customers, business knowledge, and automations.
- Sensitive operations are additionally restricted by role, so not every member can change everything.
- Privileged, service-level access is used only by server-side code, never exposed to the browser.
3. Encryption
- Data in transit is encrypted using TLS.
- Data at rest is encrypted by our managed database and storage providers.
- Third-party channel credentials and tokens are encrypted at the application layer before they are stored, in addition to storage-level encryption.
4. Channel credentials and provider access
When you connect a channel such as Gmail or WhatsApp Business, OmniInbox AI stores the credentials needed to synchronise and send messages on your behalf.
- Connections use each provider's official authorisation flow. We do not ask for your email password.
- We request the narrowest permissions needed for the features you use, and ask for additional permissions only when you enable features that require them.
- Stored credentials are encrypted and are never returned to the browser or exposed through the interface.
- Payment provider credential references are restricted to server-side, service-level access only.
- You can disconnect a channel at any time, which stops synchronisation and sending.
5. Access control and authentication
- Sign-in supports email and password, Google, and Microsoft.
- Email addresses are verified before an account becomes fully active.
- Passwords are handled by our managed authentication provider and are stored only as salted hashes.
- Workspace roles such as owner, admin, manager, and agent determine what a member can change.
- Roles are stored separately from user profiles and checked server-side, so a client cannot escalate its own permissions.
6. Webhooks and inbound requests
Inbound requests from providers are verified before they are processed. Verification tokens and signing secrets are stored as server-side secrets, and requests that fail verification are rejected without being processed.
Message content received from any channel is normalised and sanitised before it is displayed, which removes active content while keeping legitimate links usable.
7. AI safety
- AI features never send a message to your customer automatically. Suggestions are drafted for a person to review, edit, or discard.
- AI answers are grounded in your own business information. When information is missing, the assistant states that rather than inventing details.
- AI requests operate within the same workspace boundaries as the signed-in user, so an assistant cannot read another workspace's data.
- Sensitive automated actions can be gated behind human approval rules.
8. Monitoring and secure development
- Automated security scanning runs against our database policies and dependencies, and findings are triaged and remediated.
- Background jobs, synchronisation, and failures are logged so problems can be diagnosed and recovered.
- Application secrets are stored in a managed secret store and are never committed to source code.
- Changes are reviewed before release, and database changes are applied through versioned migrations.
9. Availability and backups
Our managed database provider performs regular automated backups of the platform database. Background synchronisation is designed to recover from missed provider notifications, so conversations are not permanently lost if a notification fails to arrive.
We do not currently publish a contractual uptime guarantee. If you require one, contact us to discuss your requirements.
10. Compliance status
We want to be direct about certification status: OmniInbox AI does not currently hold SOC 2, ISO 27001, or HIPAA certification, and we will not claim otherwise.
We do apply data-protection practices aligned with GDPR principles, including data minimisation, workspace-scoped access, deletion capabilities for stored knowledge and memory, and a Data Processing Addendum for customers who need one.
11. Your responsibilities
- Use a strong, unique password or sign in with Google or Microsoft.
- Invite only people who should see your customer conversations, and give each member the lowest role that fits their job.
- Remove members promptly when they leave your organisation.
- Disconnect channels you no longer use.
12. Reporting a vulnerability
If you believe you have found a security vulnerability, please report it to us privately before disclosing it publicly. We will acknowledge your report, investigate, and keep you informed of the outcome.
Email: security@omniinbox.ai
Please include the steps to reproduce, the impact you observed, and any accounts or workspaces involved. Do not access or modify other users' data while testing.
We ask that you avoid denial-of-service testing, spam, or social engineering of our team or customers.
13. Contact us
For security questions or documentation requests:
OmniInbox AI
Email: security@omniinbox.ai
Website: https://omniinbox.ai