Security

01 Our approach to security

We design for security and privacy from the start, and we apply defence in depth: protection at the network, application, data and access layers, rather than relying on any single control. We collect and process only the data needed to do the job, we keep access to the minimum required, and we hold ourselves to the data-protection commitments in our Data Processing Agreement and Privacy Policy. The measures below reflect what is in place today; our security programme continues to mature as we grow. We are currently below the size thresholds that bring providers into the mandatory scope of the EU NIS2 framework (transposed in Romania by OUG 155/2024), and we build our controls so that customers who are themselves in scope can rely on us within their supply chain.

02 Data ownership, privacy and AI

How we treat your data is itself a security decision, and a few commitments are central to how the product works:

• We do not train foundation models on your data. Your data is used to operate your Digital Employees, not to train the underlying models.
• We do not pool or share your data across customers. Each customer's data stays within that customer's environment.
• You own your data and your Contextual Memory. The data you provide, and the institutional context a Digital Employee learns within your instance, belong to you, as set out in the Data Processing Agreement.

These commitments are reinforced by purpose limitation and data minimisation: access to Customer Data is limited to the role, workflow and support need for which it is required.

03 Data residency and hosting

Core service processing takes place in the EEA. We host the core of the Service on Microsoft Azure in Germany West Central (Frankfurt), where core compute and storage remain. Foundation-model providers are reached through EU endpoints. Optional voice features may involve processing in the United States under Standard Contractual Clauses. Current sub-processors, their locations and the transfer mechanism that applies to each are listed in Annex 3 of our Data Processing Agreement.

04 Encryption

We encrypt Customer Data in transit and at rest. External traffic uses HTTPS with TLS (version 1.2 or higher), with no plaintext serving, and stored data uses AES-256 encryption. Encryption keys are held separately from Customer Data, access to key-management functions is restricted, and key-lifecycle actions are treated as security-relevant events.

05 Access control and authentication

Access to systems and Customer Data is granted on a least-privilege, need-to-know basis, with individual accounts and multi-factor authentication for administrative access. Access rights are aligned to a person's role and removed promptly when no longer needed or when someone leaves. Permissions are reviewed periodically, and elevated access is limited in time and scope where needed. Administrative and security-relevant actions are written to an append-only, integrity-chained audit log, with the audit event stream retained for 90 days.

06 Tenant and data isolation

Each customer's data is separated through layered controls at the application and data layers. Services use limited roles, customer boundaries are enforced consistently across scoped access, and automated tests verify the boundaries intended to prevent one customer from accessing another customer's data or Contextual Memory.

07 Application and infrastructure security

Changes reach production only after automated build, test and security checks on a protected branch. Release artifacts include a software bill of materials (SBOM) and are verified before deployment. Software components and container images are scanned for vulnerabilities, dependencies are kept current through controlled updates, and services produce structured logs, metrics and traces used to monitor service health, investigate issues and route relevant alerts.

08 Sub-processors and vendor management

We carry out due diligence on the third parties that process data on our behalf before engaging them, and we bind them by contract to data-protection and security obligations consistent with our own. We maintain a current list of these sub-processors, with their locations and the transfer mechanism that applies to each, in Annex 3 of our Data Processing Agreement. Components we host within our own infrastructure are part of our environment and are not third-party sub-processors.

09 Backups and recovery

We use automated daily database backups and additional restore points before high-risk maintenance. Backup health is monitored so failures can be addressed, and recovery procedures are maintained to restore availability of and access to data after an incident. Our approach to service availability is described in the Service Level Agreement.

10 Incident response

Security signals are monitored and relevant incident classes are routed for response. We maintain a process to detect, escalate and respond to security incidents. If a personal data breach affects your data, we will notify you without undue delay, give you the information you need to meet your own obligations, and work with you to contain and remediate the issue, in line with our Data Processing Agreement and applicable law.

11 Data retention and deletion

We operate on the basis of no retention of your data after our contract ends. When the contract ends, we make your data available for export through a download link available for 30 days, consistent with your right to data portability and erasure, and you can request complete deletion at your discretion. The Contextual Memory learned within your instance is treated as your data for these purposes.

12 Reporting a security issue

If you believe you have found a security vulnerability in our Service, we want to hear from you. Please see our Vulnerability Disclosure Policy for how to report it, or contact us directly: