Security and data protection
Secure development and testing
How changes to Telonic are made, reviewed, tested and released, how vulnerabilities are managed, and what is expected of the people who build and run it.
On this page
A secure product depends on how it is changed as much as on how it was first built. Every change to Telonic, whether to the platform or to your agents, is reviewed and tested before release, in an environment separate from your live one. Changes to how the agent behaves are also tested against conversations drawn from your industry, and no change of model or provider reaches your customers without your approval. This page describes how changes are made and released, how weaknesses are found and fixed, and the standards that apply to the people who do the work.
How a change reaches your deployment
Every change follows the same path, and every step is recorded.
| Step | What happens |
|---|---|
| 1. Recorded | The change is made in version control (a system that records every change, who made it and when), so every change can be traced and reversed |
| 2. Reviewed | Another engineer reviews the change before it can be merged |
| 3. Checked | Automated tests and security checks run on the change, including checks for known vulnerabilities in the components it uses |
| 4. Tested for your industry | Changes that affect how the agent behaves run against regression suites (sets of tests that confirm existing behaviour still works) built from your industry's conversations |
| 5. Tried in test | The change runs in a test environment, separate from your live one, before any customer sees it |
| 6. Approved | Changes that need your approval, including any change of model or provider, wait for it |
| 7. Released | The change goes live, and can be reversed if needed |
Testing the agent, not only the code
Code tests confirm that the software works. They cannot tell you whether the agent still handles a disputed snagging item or a rebooking within fare rules correctly. For that, Telonic keeps evaluation sets for each industry: test conversations drawn from real conversation patterns, each scored against what a correct outcome means in that industry. Regression suites built from them run before every release.
A new language model (the AI model that understands the conversation and decides the reply) is adopted only when it performs at least as well on the industry test set as the model it replaces. Conversation simulation (testing the agent against realistic scenarios before go-live, the point at which it starts handling real customers) is configured during implementation. See Testing before every release.
Finding and fixing weaknesses
| Practice | How it works |
|---|---|
| Dependency management | Third-party software components are tracked, and kept up to date |
| Vulnerability management | Components and infrastructure are scanned for known vulnerabilities. Fixes are prioritised by severity, with the most severe fixed first |
| Independent penetration testing | Independent testers carry out penetration testing (an authorised, simulated attack to find weaknesses) at least once a year and after major changes. Findings are fixed in order of severity, and a summary is available to your security team under a non-disclosure agreement |
| Secrets management | Credentials and keys are held in a secrets store (a service built to hold credentials securely), never in code or configuration files |
Change control with you
Changes follow a documented change control process. You are told before any significant change to your deployment, and changes to your agents' behaviour, such as limits, topics or escalation rules, are released through the process described in How changes go live. Every change to an agent is recorded, so you can see what changed, when, and who approved it.
The people who build and run Telonic
Engineers who can reach customer environments pass background checks before they are given access. Everyone at Telonic completes security training when they join and at regular intervals after that. Access is removed when someone changes role or leaves.
Access to customer deployments is limited to named engineers, from the UAE or the country you choose, for a limited time, and every access is logged. See Access control and single sign-on.
In practice
Nakhla Travel, a tour operator, runs agents for bookings and changes.
- A newer language model becomes available in Nakhla Travel's region. An engineer records the change in version control, and a second engineer reviews it.
- Automated tests and security checks pass. The regression suite for travel runs: booking enquiries, changes within fare rules, and messages about delays and cancellations.
- The new model performs at least as well as the old one. The results are shared with Nakhla Travel's operations lead.
- The change runs in the test environment, where Nakhla Travel's team tries its own difficult cases.
- Nakhla Travel approves the change, and it is released. The record shows what changed, when and who approved it.
What your team controls
- Approval of any change of model or provider before it goes live.
- Approval of changes to your agents' limits, topics and escalation rules, through the controls your team holds.
- Requesting the latest penetration test summary under a non-disclosure agreement.