Security in Rootlenses Voice

22. Security controls

Rootlenses Voice incorporates security and governance controls designed to protect voice campaign operations, restrict critical changes to authorized users, and maintain traceability over sensitive configurations such as agents, COTs, business rules, telephony providers, notification providers, transfer numbers, realtime models, and call results.

Security within Rootlenses Voice is not based solely on restricting access. Instead, it combines permissions, validations, traceability, version control, operational auditing, and configuration best practices. This approach enables teams to create, test, deploy, and continuously improve voice agents with greater control while reducing risks associated with incorrect configurations, unauthorized changes, unnecessary exposure of information, or unexpected behavior during campaign execution.

1. Security from the Initial Agent Configuration

The security of a campaign begins before the agent places its first call. Every component configured in Rootlenses Voice directly impacts the contact experience, operational quality, and the level of control the team maintains over the conversational flow.

Before launching a campaign, it is important to verify:

• That the COT is properly defined and approved.
• That the selected voice is appropriate for the campaign objectives.
• That retry rules align with the contact strategy.
• That execution schedules prevent calls outside approved business hours.
• That the telephony provider and outbound phone number are active.
• That transfer numbers are configured correctly.
• That pre-launch testing confirms the expected agent behavior.

2. Access Control and Permissions

Access management is one of the fundamental pillars of security within Rootlenses Voice. The platform enables organizations to organize permissions so that only authorized users can view, create, or modify critical operational configurations.

This applies especially to components such as:

• Voice agents.
• COTs and conversational flows.
• Business rules.
• Retry rules.
• Execution schedules.
• Telephony providers.
• Notification providers.
• Transfer numbers.
• Realtime models.
• Templates and active versions.
• Call results, recordings, and transcripts.

A well-designed permission model helps reduce the risk of accidental changes, incorrect configurations, or modifications made by users without the appropriate context. It also enables responsibilities to be distributed among administrators, campaign specialists, sales teams, operations teams, and read-only users.

The goal is not to restrict team productivity, but to ensure that every user has access only to the actions required to perform their role within the platform.

3. Protection of Call-Generated Information

Every call made through Rootlenses Voice can generate operational and sensitive information. This data is essential for analyzing results, improving agents, and making business decisions, but it must be handled with appropriate access controls and review procedures.

The information generated or displayed may include:

• Customer or contact name.
• Dialed phone number.
• Line status.
• Call outcome.
• Call start date and time.
• Call end date and time.
• Call duration.
• Interest level.
• Recommended follow-up method.
• Contact information identified during the conversation.
• Call recording.
• Complete transcript.
• Automatically generated call summary.
• Call termination details indicating whether the user or the agent ended the call.

Due to the nature of this information, Rootlenses Voice should be operated following data access, review, and handling best practices. Recordings, transcripts, and call results should only be accessed by authorized users for legitimate operational purposes.

This allows organizations to leverage valuable feedback without unnecessarily exposing customer or campaign information.

4. Security for Recordings, Transcripts, and Feedback

Recordings and transcripts are high-value assets within Rootlenses Voice because they allow organizations to understand how conversations developed, verify that the agent followed the defined conversational flow, and identify opportunities for continuous improvement.

However, they must also be handled carefully because they may contain sensitive information shared during interactions.

For this reason, access to recordings, transcripts, and feedback should be limited to authorized roles and reviewed only for clearly defined purposes such as:

• Evaluating conversation quality.
• Detecting errors in COT execution.
• Verifying that the agent followed the conversational flow.
• Confirming whether genuine user interaction occurred.
• Reviewing dropped or incomplete calls.
• Improving the agent's tone, pacing, messaging, and timing.
• Prioritizing contacts based on interest level.
• Defining follow-up actions after the call.

Proper management of this information allows every call to become a valuable learning opportunity without compromising operational privacy or control over generated data.

5. Technical Protection of Credentials and Sensitive Data

Rootlenses includes mechanisms to protect sensitive configurations in applicable components, including application-level encryption and the separation of critical configurations from the source code.

Additionally, based on technical validation conducted with the engineering team, information associated with conversations is protected through database-level encryption. This reinforces the protection of sensitive data generated during interactions between end users, agents, and the platform.

In this context, data protection goes beyond display permissions by incorporating technical mechanisms that reduce the risk of exposing stored information.

These capabilities should be communicated carefully: Rootlenses protects credentials, sensitive configurations, and conversation-related information in applicable components, but full encryption of all platform information should not be claimed without additional technical validation.

6. API, Session, and Embedded Access Security

Rootlenses Voice relies on authentication, authorization, and access validation mechanisms to protect sensitive platform operations. These controls help ensure that actions such as viewing call results, accessing recordings or transcripts, modifying rules, editing agents, changing providers, or updating critical configurations can only be performed by authorized users or services.

Where applicable, the platform uses user authentication, permission controls, authentication tokens, authenticated sessions, and validation checks before granting access to protected resources.

API protection also relies on administrator-generated authentication tokens. These tokens control access to specific services and are associated with designated hostnames, helping restrict their use to authorized environments. In addition, access requires HTTPS validation, reinforcing secure communication between authorized components and the platform.

This approach helps reduce risks associated with unauthorized access, exposure of sensitive information, or execution of critical changes without sufficient permissions.

For external communications, this capability should be described as protection through authentication, authorization, tokens, and applicable permission controls, avoiding claims that every service uses exactly the same security mechanism.

7. Traceability and Operational Auditing

Traceability makes it possible to understand what happened within the platform, who made a change, when it occurred, and which configuration was active at a given point in time. In Rootlenses Voice, this capability is particularly important because many configurations directly impact agent behavior and the customer experience.

Traceability is associated with capabilities such as:

• Template version management.
• Rule management.
• Changes to COTs.
• Provider modifications.
• Activation or deactivation of configurations.
• Retry rule updates.
• Execution schedule changes.
• Transfer number updates.
• Selection or modification of realtime models.
• System notification management.

Traceability helps answer operational questions such as:

• Who modified this rule?
• When was this COT updated?
• Which template version was active during a campaign?
• Which configuration was in place before an incident occurred?
• Which change may have affected the agent's behavior?
• Which user performed a critical modification?

This approach reduces dependency on individual knowledge while facilitating error recovery, incident investigation, and continuous product improvement.

8. Security in Template Version Management

Template version management provides an important layer of operational security because it allows changes to be made without losing historical records or overwriting previous configurations.

Each version retains relevant information such as:

• Creation date.
• Responsible user.
• Chronological order of modifications.
• Identification of the active version.
• The ability to compare versions.
• The ability to revert by creating a new version based on a previous one.

This enables controlled template evolution, validation of changes before promoting them to active status, and recovery of previous configurations whenever necessary.

From a security and governance perspective, version management helps:

• Reduce the impact of human error.
• Prevent the loss of stable configurations.
• Maintain a complete change history.
• Facilitate internal audits.
• Compare modifications before reverting.
• Recover more quickly from operational errors.

Reverting to a previous version should not be understood as erasing the past, but rather as moving forward safely using a previously validated configuration.

9. Security in the Rules Engine

The Rules Engine is a key component of Rootlenses Voice's operational security because it centralizes decisions that would otherwise be scattered across multiple configurations or depend on settings that are difficult to track.

Through rules, the platform can control behaviors such as:

• Retry attempts.
• Execution schedules.
• Offset handling and calls outside scheduled hours.
• Transfer logic.
• Operational workflows.
• Agent-specific or stack-specific rules.
• Global or entity-specific rules.
• Rule execution priority.
• Allowed conditions and operators.

From a security perspective, this ensures that important operational decisions remain explicit, reviewable, and governed. A poorly configured rule can negatively affect the customer experience by generating excessive contact attempts, calling outside permitted hours, or triggering incorrect transfers.

Therefore, the Rules Engine helps reduce risks through:

• Condition validation.
• The use of metadata to restrict permitted fields and operators.
• Version control for rule changes.
• Priority-based rule evaluation.
• Separation between business logic and technical implementation.
• Greater predictability of agent behavior.

This approach transforms automation into a governed capability, allowing operational decisions to evolve without sacrificing control.

10. Security in Retry Attempts and Execution Schedules

Retry attempts should not be viewed as automatic persistence but rather as an operational control mechanism. A well-designed configuration helps recover contact opportunities without creating friction, oversaturation, or a negative user experience.

From a security and governance perspective, retry rules help prevent:

• Excessive retry attempts.
• Calls outside approved business hours.
• Oversaturation of a single phone number.
• Contact fatigue.
• Increased call blocking or rejection.
• Operational inefficiencies caused by unclear rules.
• Failure to comply with defined contact windows.

Elements such as retry intervals, the maximum number of attempts, weekend exclusions, and the selection of phone numbers for retries should be configured according to the contact strategy and campaign type.

A secure operation is not simply about making more calls, but about making better calls: at the right time, with the appropriate frequency, while respecting the end user's experience.

11. Security for Providers and Integrations

Rootlenses Voice relies on multiple providers and integrations that must be managed carefully because they directly impact campaign execution, system communications, and the overall user experience.

Sensitive components include:

• Telephony providers.
• Outbound phone numbers.
• Transfer numbers.
• SMTP providers.
• System notifications.
• Realtime models.
• Billing and credit configurations.
• Resources associated with agents and campaigns.

These components should be managed using appropriate permissions, prior review, and controlled testing. Before using a provider, phone number, or model in a large-scale campaign, organizations should validate that the configuration is correct and aligned with the intended operational objectives.

Centralized provider management helps organizations:

• Quickly identify the active provider.
• Distinguish default providers.
• Reduce configuration errors.
• Review recent changes.
• Maintain order in environments with multiple providers.
• Reduce technical dependency for operational configurations.

12. Security for System Notifications

The Notifications Module contributes to the governance of Rootlenses Voice by centralizing the management of system communications and providing greater visibility into which notifications exist, which are active, and how they are managed.

From an operational security perspective, notifications help maintain control over relevant events, configurations, and changes that may impact users or administrators.

This module allows organizations to:

• View available notifications.
• Identify active notifications.
• Manage delivery providers.
• Review recent configuration changes.
• Maintain consistency across system communications.
• Reduce errors caused by incorrectly configured providers.
• Prepare the platform for new notification channels or notification types.

Additionally, when notifications are associated with important operational events, they help teams stay informed about relevant changes such as user creation, provider updates, cron modifications, or other significant operational adjustments.

13. Infrastructure, Environments, and Observability

Rootlenses Voice is built on an architecture designed to protect each customer's operations through resource isolation, controlled configuration management, and foundational observability capabilities. Based on technical validation with the engineering team, each customer operates with an independent database, a dedicated Virtual Private Network (VPN) connection, and customer-specific security groups, helping restrict access to internal resources and reducing the risk of cross-customer exposure.

This separation helps ensure that one customer's information is never mixed with another's and that user sessions remain isolated within their own operational context. In other words, every conversation and session is managed independently, preventing information from being shared across customers or sessions.

Environment separation also allows organizations to validate changes before they impact production operations, reduce configuration risks, and maintain greater control over active campaigns. Additionally, credentials, encryption keys, and sensitive configurations should be managed outside the source code using appropriate security controls to avoid unnecessary exposure of critical information.

From an observability perspective, Rootlenses provides foundational capabilities for recording events, analyzing relevant system behaviors, and tracking operational activities across platform components. These capabilities contribute to improved traceability, incident investigation, and operational continuity.

Features such as backups, disaster recovery, redundancy, 24/7 monitoring, Web Application Firewalls (WAF), or other infrastructure-specific capabilities should be validated with the technical team before being communicated as official guarantees.

14. Security in Realtime Model Selection

Selecting the realtime model used by a voice agent is also part of operational governance. Changing the model version can impact latency, operating costs, conversational quality, and the overall behavior of the agent during live calls.

For this reason, model selection or upgrades should be performed in a controlled manner and ideally validated before large-scale deployment.

This capability allows organizations to:

• Evaluate agent performance.
• Balance latency and operational cost.
• Test new model versions before broad deployment.
• Reduce risks associated with unexpected conversational behavior.
• Maintain greater stability in production campaigns.
• Align the selected model with campaign objectives.

A secure operation requires validating that the selected model responds appropriately to the COT, the expected tone, the conversational flow, and the business rules defined for the agent.

15. Security in the Use of RAG and Context Documents

Retrieval-Augmented Generation (RAG) enables the agent to use external information as context to deliver more accurate responses. While this capability significantly increases the value of the agent, it also requires best practices for selecting, uploading, and maintaining context documents.

Documents used as context may contain valuable information related to sales, customer support, data validation, or internal processes. Therefore, they should be well-structured, up to date, and aligned with the objectives of the campaign.

For secure and effective use of RAG, it is recommended to:

• Upload only the documents required for the agent's intended purpose.
• Avoid disorganized, duplicated, or ambiguous documents.
• Verify that the information is current and accurate.
• Exclude information that the agent should not use during conversations.
• Validate responses through test calls before production deployment.
• Restrict document upload and modification permissions to authorized users.
• Use clear, structured, and specific content.

A well-managed RAG implementation helps reduce hallucinated, inconsistent, or incomplete responses while improving the reliability of the agent throughout customer interactions.

16. Security in COT and Conversational Flow

The COT defines how the agent thinks, responds, and behaves during a conversation. For this reason, it should be treated as a critical configuration within Rootlenses Voice.

A poorly designed COT may lead to inconsistent responses, out-of-context behavior, unwanted sales attempts, incorrect transfers, or inappropriate call conclusions.

To strengthen the operational security of the COT, it is recommended to:

• Clearly define the agent's role.
• Specify the organization the agent represents.
• Clearly state the purpose of the call.
• Define both expected and prohibited behaviors.
• Include response examples.
• Create clearly defined conversational states.
• Define transitions between conversation states.
• Include critical rules regarding silence, interruptions, IVR interactions, and call termination.
• Test the conversational flow before launching large-scale campaigns.

A well-designed COT minimizes model improvisation and helps ensure that every conversation remains within the operational boundaries defined by the organization.

17. Security in Human Call Transfers

Transferring a call to a human representative is a sensitive operation because it connects the contact with a team outside the AI voice agent. Therefore, both the transfer number and the logic that triggers this action must be configured carefully.

Before enabling transfers, organizations should verify:

• That the transfer number is correct.
• That the human team is prepared to receive transferred calls.
• That transfer conditions are clearly defined within the conversational flow.
• That the COT specifies when transfers should occur.
• That business rules do not accidentally trigger transfers.
• That transfer scenarios have been thoroughly tested.
• That users clearly understand when they will be escalated to a human representative.

Properly configured transfers improve the customer experience and help prevent missed business opportunities, while incorrect transfer configurations may create friction, interruptions, or unnecessary escalations.

18. Security in Credits, Billing, and Operational Usage

The credit system is part of Rootlenses Voice's operational governance because it enables organizations to monitor and control resource consumption associated with voice campaigns. The purchase and administration of credit packages should remain visible and controlled to avoid unexpected consumption or service interruptions during critical campaigns.

Credits allow organizations to extend platform usage when the credits included in their current subscription plan are insufficient. However, purchasing and managing credit packages should be restricted to users with the appropriate permissions.

Recommended best practices include:

• Review the available credit balance before launching campaigns.
• Verify which users are authorized to purchase additional credits.
• Confirm the associated payment method.
• Verify that purchased credits are correctly assigned to the account.
• Monitor credit consumption during high-volume campaigns.
• Avoid large-scale campaign execution without confirming sufficient available credits.

These practices help maintain financial predictability while ensuring uninterrupted operational continuity.

19. DevOps/SecOps Best Practices and Responsible Compliance Communication

Rootlenses Voice approaches security as a continuous practice throughout the configuration, development, deployment, and operational lifecycle. Beyond the security controls visible to end users, the platform relies on best practices designed to protect sensitive configurations, reduce operational errors, and maintain traceability over critical changes.

Applicable best practices include:

• Separating sensitive configurations from the source code.
• Validating changes before large-scale deployments.
• Using separate environments for development, testing, and production where applicable.
• Restricting access to critical platform components.
• Validating user input and configuration changes.
• Versioning important configurations.
• Logging relevant events for operational traceability.
• Periodically reviewing providers, rules, models, and user permissions.
• Conducting controlled testing before production campaigns.

These practices align with general application security principles, operational governance, and continuous improvement. However, they should not be presented as formal certifications or regulatory compliance unless official validation has been obtained.

For this reason, any statements regarding ISO 27001, SOC 2, HIPAA, GDPR, or other formal compliance standards should be verified before being included in commercial or marketing materials.

20. Recommended Best Practices for Secure Operations

To maximize the security, traceability, and reliability of Rootlenses Voice, the following best practices are recommended before, during, and after every campaign:

• Review user permissions before granting access.
• Define clear roles for administrators, operators, and read-only users.
• Validate the COT before launching the campaign.
• Review RAG documents and remove unnecessary information.
• Test the selected voice before deploying it to production.
• Confirm that the outbound phone number is correct.
• Validate transfer numbers.
• Review retry rules, execution schedules, and weekend exclusions.
• Perform test calls using the final configuration.
• Confirm that the selected realtime model is appropriate.
• Review provider configurations before launching large-scale campaigns.
• Restrict access to recordings and transcripts to authorized users only.
• Maintain control over active versions of templates and rules.
• Review campaign feedback after every deployment.
• Refine the COT, voice, business rules, and RAG documents based on real operational evidence.
• Avoid implementing critical changes without prior review.
• Maintain traceability for sensitive configurations.
• Periodically review providers, permissions, and active rules.

Following these practices helps create a more predictable, secure, and business-aligned operational environment.

21. Language for Technical and Non-Technical Audiences

This documentation is designed to be understood by both technical and non-technical users. For this reason, each security capability is explained from the perspective of its operational impact and, where appropriate, is complemented by a high-level technical reference.

For non-technical audiences, the document explains how Rootlenses Voice helps control access, protect information generated during calls, reduce operational errors, maintain traceability, and validate configurations before large-scale campaigns.

For technical audiences, the documentation includes concepts such as authentication, authorization, permissions, sessions, credential protection, request validation, auditing, logging, environment separation, observability, and DevOps/SecOps best practices, without exposing sensitive internal implementation details or making unverified claims.

22. Security Capabilities That Can Be Communicated to Customers

Rootlenses Voice incorporates capabilities designed to protect voice campaign operations, control access, maintain traceability, and reduce risks associated with critical configurations.

The platform can confidently communicate that it provides the ability to:

• Manage access through authentication, permissions, and role-based access control.
• Restrict critical changes to authorized users.
• Protect credentials and sensitive configurations in applicable components.
• Protect conversation-related information through database-level encryption.
• Isolate customer information through independent databases.
• Protect access to internal resources using VPN connectivity and customer-specific security groups.
• Maintain session isolation to prevent information from being shared across customers or conversations.
• Protect APIs using administrator-generated authentication tokens associated with authorized hostnames.
• Reinforce secure communications through HTTPS validation where applicable.
• Maintain traceability for important configurations.
• Version templates to preserve history and simplify recovery.
• Govern business rules, execution schedules, and retry strategies.
• Validate configurations before large-scale campaign deployments.
• Review call results, recordings, and transcripts through components protected by authentication and authorization controls.
• Manage providers and integrations from centralized configuration modules.
• Use call feedback to improve voice agents and reduce operational errors.
• Configure and validate voice agents through testing before scaling them into production.

These capabilities help deliver a more secure, reliable, and well-governed operation for both customers and internal teams by maintaining control over access, configurations, campaign results, and the continuous evolution of voice agents.

However, claims such as full encryption at rest across the entire platform, guaranteed backups, 24/7 monitoring, high availability, Web Application Firewall (WAF) protection, VPN architecture, formal compliance with external standards, or complete protection against all vulnerabilities should not be communicated publicly without additional technical validation.