Security Overview
This Security Overview is published by the Company. The Company's full identity, address, and legal contact details appear at the bottom of this page.
The security of your data and of your end users' data is a condition of the Service's existence, not a feature among others. This document describes, in plain language, the technical and organizational controls actually in place on the Platform — data isolation, encryption, access management, logging, oversight of subprocessors, and incident handling. We have chosen to be precise rather than exhaustive: every statement below corresponds to a verifiable control, and we would rather honestly describe what exists today than imply more than we can demonstrate.
Table of Contents
- Our approach to security
- Data isolation between Customers
- Encryption
- Access management
- Logging and audit
- Security of our subprocessors
- Security incident management
- Reporting a vulnerability
- Our certification posture
1. Our approach to security
> In short: security is built into the Platform's design, not bolted on afterward — and our program keeps evolving as the Service grows.
The Service hosts AI conversational agents (text and voice) operating on behalf of multiple customer organizations on shared infrastructure. This multi-tenant reality shapes our security philosophy: every control described in this document starts from the principle that no customer organization should ever be able to access, directly or indirectly, another organization's data.
We apply a security-by-design approach: the controls governing isolation, access, and traceability are not peripheral additions but structural properties of how the Platform is built, at both the database and application levels. This approach goes hand in hand with a principle of least privilege — each component, each role, and each integration receives only the access strictly necessary for its function.
We are also transparent about the fact that a security program is, by nature, ongoing work rather than a state reached once and for all. We document our controls, we evolve them as the Platform and the threat landscape change, and we would rather present this work as it is — real, measurable, and continuously improving — than present it as finished.
2. Data isolation between Customers
> In short: each customer organization's data is separated at the database level itself, not only at the application level.
The Service is built on a multi-tenant architecture in which multiple customer organizations share the same application infrastructure. Isolation between these organizations is enforced at the database level, by means of a row-level security policy, systematically applied to tables holding data belonging to multiple Customers.
In practical terms, this means that access to data is not filtered only by application logic — which could contain a programming error — but is also constrained directly by the database engine itself, on every query. A query that attempted, by error or by malicious intent, to read or modify data belonging to a customer organization other than that of the authenticated user is blocked at the source by this policy. This double layer — application and database — substantially reduces the risk that an isolated software failure could result in a data leak between Customers.
3. Encryption
> In short: your data is encrypted while in transit to and from our servers, and at rest through the encryption mechanisms of our hosting infrastructure.
All communications between users, integrations, and the Platform are encrypted in transit using the TLS (Transport Layer Security) protocol. No data is transmitted in the clear over the public network between your browser, your integrated systems, and our servers.
Data at rest — that is, data stored in our databases and file systems — is protected by encryption meeting industry standards, provided by our underlying hosting infrastructure. We rely on recognized infrastructure providers whose at-rest encryption mechanisms are part of the hosting platform's base offering, rather than operating a separate encryption layer of our own at this level.
4. Access management
> In short: access to the administrative space is role-based, following the principle that each person is granted only the rights their function requires.
The Platform's administrative space applies role-based access control. Each administrative user is assigned a role that precisely determines the actions they can perform and the data they can access, rather than undifferentiated global access.
This approach follows the principle of least privilege: the rights granted to a role correspond to exactly what is strictly required to perform the associated function, and nothing more. Elevated-privilege access — such as management of Service-wide settings or access to sensitive data across multiple customer organizations — is reserved for a limited number of roles defined for that purpose.
For the sake of accuracy, we clarify that this document does not present multi-factor authentication as a mechanism currently guaranteed across the entire Platform; we would rather state nothing on this point than describe a control that is not uniformly in place.
5. Logging and audit
> In short: sensitive and administrative actions are logged with a timestamp, the identity of the actor, and, where relevant, the stated reason for the action.
The Platform maintains an audit log of sensitive and administrative actions performed by users with elevated access. Each log entry is timestamped and associated with the actor who performed the action, making it possible to reconstruct who did what, and when.
Where the context calls for it, these logs also retain the stated reason for the action, adding a further layer of traceability for significant administrative operations. This logging supports both our own anomaly-detection capabilities and, where applicable, a Customer's need to investigate actions taken within their own environment.
6. Security of our subprocessors
> In short: we exercise due diligence on the providers and subprocessors involved in operating the Service, and we publish the list of them.
Like any modern SaaS platform, the Service relies on a set of infrastructure providers and third-party services — notably for hosting, data processing, and certain specialized capabilities (for example, the underlying artificial intelligence or speech synthesis capabilities behind the conversational agents). We do not name these providers in this document.
We apply due diligence in selecting and monitoring these subprocessors before entrusting them with any data processing related to the Service. The current list of subprocessors involved in processing the Service's data, along with the nature of the processing entrusted to them, is available in our Subprocessor List, a separate document that is kept up to date and made available to Customers.
7. Security incident management
> In short: we have a process for detecting, containing, and handling security incidents, and we honor our legal notification obligations when an incident affects personal information.
A security incident refers to any event that compromises, or could compromise, the confidentiality, integrity, or availability of data processed by the Service. Our approach to incident management rests on three stages: detecting the event, containing its impact to limit its scope, and then analyzing and remediating the underlying cause.
When a security incident affects the personal information of a Customer or its end users, we notify the affected parties within a reasonable timeframe, in accordance with applicable legal obligations — including those set out under Quebec's Act to modernize legislative provisions as regards the protection of personal information (Bill 25), Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), and any other applicable personal information protection law depending on the Customer's jurisdiction. We do not commit here to a specific numerical timeframe: each incident differs in its nature, scope, and investigative complexity, and our communications reflect the information available at the point it can be reliably shared, in keeping with the applicable legal framework.
8. Reporting a vulnerability
> In short: if you believe you have found a security flaw in the Service, we want to know about it quickly and responsibly.
We welcome good-faith reports of potential security vulnerabilities in the Service. If you identify what you believe to be a security flaw, we ask that you disclose it to us responsibly — meaning that you do not exploit the vulnerability beyond what is strictly necessary to demonstrate its existence, that you do not access data that does not belong to you, and that you do not publicly disclose the information before we have had a reasonable opportunity to address it.
To report a vulnerability, please use the contact details shown at the bottom of this page. We acknowledge receipt of reports we receive and commit to following up on them diligently.
9. Our certification posture
> In short: our security controls are real and documented, but we have not, to date, obtained any formal third-party certification — a normal posture for a growing SaaS, and one we prefer to state clearly.
Many SaaS platforms display third-party certifications such as SOC 2 Type II or ISO 27001. We choose not to claim any such certification until it has been formally obtained and audited by an independent third party. To date, our security program rests on documented, verifiable internal controls — those described in the preceding sections of this document — rather than on an external label.
This is a deliberate posture, typical of a growing organization investing in the continuous maturation of its security practices: we would rather honestly document what is in place today and evolve this program rigorously, than display a certification that would not faithfully reflect our current state. We periodically assess whether to pursue formal certification, and any development on this front will be reflected in an updated version of this document.