Voicebot Security: How Can Businesses Protect Their Voice Assistants From Attacks?

Voicebots are now answering customer enquiries, accessing company data and in some cases even completing business processes autonomously. That also makes them an increasingly attractive target for attackers. Any organisation deploying voice assistants in customer service should therefore understand the associated risks – and how to mitigate them.

The challenge is compounded by a second development: many employees are already using their own AI tools in their day-to-day work, often without the knowledge or approval of the IT department. This phenomenon has become known as shadow AI.

At the same time, customers and businesses are placing increasing trust in AI-generated responses as the quality of these systems continues to improve. Ironically, that growing trust makes voicebots an even more attractive target for cyberattacks.

What Attacks on Voicebots Really Pose a Threat

Security risks associated with AI can now be categorised quite quickly. One of the best-known frameworks is provided by the OWASP (Open Web Application Security Project) community. OWASP is a non-profit organisation that has been promoting best practice in cybersecurity for many years. It regularly publishes its well-known Top 10 lists of security risks together with practical guidance on how to address them. More recently, it has also launched the GenAI Security Project, which focuses specifically on the risks associated with generative AI.

One of the most significant risks identified by OWASP is prompt injection. This occurs when a caller uses carefully crafted prompts to manipulate the AI into performing actions it was never intended to perform, such as disclosing confidential information or offering unauthorised discounts. It’s similar to a confidence trick carried out over the telephone, except that the attacker is manipulating an AI system rather than a human being. Increasingly, these attacks are being carried out automatically.

Prompt injection is only one of several attack vectors. AI models can also be overwhelmed with requests, creating a form of denial-of-service attack. Under excessive load, a model may fail unpredictably, ignore intended safeguards, or produce responses that it would not normally generate. Language models may also expose internal information, reveal implementation details, or process content that they should reject altogether. Watch our Video

Another important risk arises from the integration of AI with knowledge management systems and Retrieval-Augmented Generation (RAG). Many voicebots rely on extensive corporate knowledge bases to answer specialised customer enquiries. If these integrations are not properly secured, attackers may be able to manipulate the underlying data, influence the model’s responses, or retrieve information that should never be accessible.

The same applies to integrations with CRM and ERP systems, as well as APIs and other software interfaces. These integrations have long been a common source of vulnerabilities in traditional software environments, and AI systems only increase their importance. Sensitive information can leak through poorly secured interfaces, while connected tools that allow AI agents to interact with external applications have increasingly become targets for attack. In recent months, researchers have demonstrated attacks in which unauthorised code was executed or credentials were extracted through vulnerable integrations.

The range of potential attacks is therefore broad. Protecting AI systems requires multiple layers of defence rather than a single security control.

A sensible starting point is to define the AI agent’s role clearly from the outset and establish strict boundaries. It should not process certain categories of information, grant unauthorised discounts, or make legally binding commitments. Decisions of that nature should always remain under human control.

Equally important is the reliable verification of callers, for example through customer identifiers, IBAN verification, or, preferably, multi-factor authentication (MFA), where an additional authentication factor – such as a code sent to a registered mobile device – is required. This significantly reduces the likelihood of automated attacks succeeding.

No single safeguard is sufficient on its own. Effective protection comes from combining multiple security controls into a layered defence – an approach widely known as defence in depth. The following sections outline the three key building blocks of such a security strategy.

Three Ways to Protect Voicebots Effectively

To address these risks, three approaches have become established in practice:

• Guardrails integrated directly into the voicebot platform,
• Adaptive protection tools that can be deployed as an additional measure,
• penetration testing, which allows simulated attacks to be carried out to uncover vulnerabilities before a real attacker does.

Integrated Guardrails in Voicebot Platforms

Built-in guardrails are a sensible starting point because they are integrated directly into the voicebot platform you are already using, without requiring any additional software or separate licensing. Most leading platforms now include their own security controls as standard.

NiCE Cognigy

NiCE Cognigy provides configurable Safety Settings for AI agents. These settings allow organisations to define different categories of safety controls. While the documentation explains the purpose of each category, it does not always provide detailed information about how individual settings behave in practice. For production deployments, it is therefore advisable to work closely with the implementation partner or the vendor to understand exactly how each control operates and how it should be configured.

The main advantage of built-in guardrails is that they are integrated directly into the platform. This typically introduces only minimal latency. However, some safeguards rely on additional prompts or system instructions, which can increase token consumption.

Parloa

Parloa provides more granular control over guardrail configuration. For many guardrail categories, organisations can choose different protection levels, such as Low, Medium or High. It also supports custom filters, allowing specific terms, topics or scenarios to be defined in which the bot should either respond differently or terminate the interaction.

As guardrail capabilities continue to evolve, platforms are increasingly moving beyond isolated content filters towards conversation-level analysis, evaluating the context of an entire interaction rather than individual prompts and responses in isolation. As with any built-in guardrails, these controls provide an effective first layer of protection, although they may also increase token consumption because additional instructions are processed alongside the conversation. A prompt is the input provided by a user, system or AI agent that instructs a language model to generate a response or perform a specific task.

Adaptive Protection Tools: Cisco AI Defense

These types of tools become particularly valuable when built-in guardrails alone are no longer sufficient – for example, where multiple bots and platforms need to be monitored centrally, or where security teams require vendor-independent oversight across different AI environments.

One example is Cisco AI Defence. Cisco has long been established in networking and cybersecurity and has expanded its portfolio in recent years to address the growing security challenges associated with AI.

One of its core capabilities is semantic inspection. This places a security layer between the AI application- for example, a voicebot – and the large language model (LLM). The system analyses the flow of information and can identify suspicious prompts, responses, or patterns of behaviour before they reach the model or the user.

As with any intermediary security layer, latency needs to be considered. Depending on the architecture, semantic inspection may introduce additional processing delays. Compatibility is another important factor. Not every voicebot or Agentic AI platform is sufficiently open to allow a third-party security solution to sit directly between the application and the LLM. In some cases, integration is only possible through APIs, while in others there is no access to the model or the underlying text stream at all.

Another important layer of protection is the monitoring of connected APIs. This includes integrations with knowledge bases, CRM and ERP systems, customer databases and other applications from which the AI reads or to which it writes data.

Cisco’s Runtime Protection helps secure these integrations by monitoring API activity, detecting suspicious access attempts and blocking malicious actions where necessary. The objective is to minimise both the likelihood and the potential impact of a compromised AI application.

Additional capabilities – including Secure Access, workspace integrations, AI Assistant, and AgenticOps – can further strengthen an organisation’s security posture. Even so, the human-in-the-loop principle remains essential. Ultimately, a human administrator should retain responsibility for critical decisions, such as temporarily disabling a bot or approving a recommended action.

Damovo Managed Service: Voicebot Penetration Testing

The third approach is a penetration testing service developed by Damovo. While penetration testing has been available for chatbots for some time, equivalent testing for voicebots has remained relatively limited.

The reason is straightforward. Although a voicebot can be tested manually, the sheer number of potential attack vectors – estimated at around 500 – makes comprehensive testing both time-consuming and resource-intensive. In addition, the attack prompts need to be tailored to the specific industry, whether that is banking, insurance, healthcare or another sector.

Damovo therefore follows a structured methodology. The process begins with the creation of test prompts that are customised for the customer’s industry. These prompts are then mapped to the relevant OWASP GenAI risk categories.

An automated testing bot then places calls to the target voicebot. After the initial greeting and, where applicable, the authentication process, the predefined test dialogues are executed. Both sides of the conversation are recorded separately, allowing the prompts and the voicebot’s responses to be analysed independently.

Each test dialogue is transcribed and enriched with metadata, creating a complete and auditable evidence trail. An AI-assisted analysis then determines whether the simulated attack was successful, whether the voicebot correctly blocked the request, or whether it disclosed information that should have remained protected.

The customer receives a detailed report that maps the findings to the relevant OWASP GenAI risk categories and includes the supporting evidence for each identified vulnerability.

What it All Costs And How Much Work is Involved

Costs

For voicebots currently in use, built-in guardrails typically do not incur any direct additional costs. However, they can lead to indirect costs through increased token consumption. At present, it’s difficult to quantify the additional consumption accurately, as there is little published data on the subject. As guardrail capabilities continue to evolve, however, it’s likely that more advanced features will require additional licensing – for example, where a separate large language model (LLM) analyses the context of an entire conversation in the background.

Adaptive protection tools are enterprise-grade solutions and typically involve implementation, maintenance and licensing costs. Depending on the vendor and the scope of deployment, these costs can be significantly higher than those associated with built-in platform capabilities.

The managed penetration testing service is designed primarily for one-off assessments and is generally far more cost-effective than deploying enterprise security software on a permanent basis. However, developing realistic test prompts requires them to be tailored both to the relevant industry and to the organisation’s specific use cases, which increases the initial project cost.

Whether such testing is carried out as a one-off exercise, after the introduction of a new capability, or on a regular basis depends on the organisation’s security requirements and risk profile.

Maintenance Effort

The three approaches also differ in terms of ongoing maintenance effort. Integrated guardrails require very little maintenance because they are already built into the platform. Adaptive protection tools involve a medium to high level of effort, particularly during the initial implementation phase. Penetration testing requires a moderate level of effort, mainly due to the need for industry-specific customisation.

Latency

The three approaches also differ in terms of latency. Integrated guardrails are typically embedded within the platform itself and therefore introduce only minimal delays. Adaptive protection tools may add additional latency, depending on the underlying architecture and integration approach. Penetration tests should generally be conducted outside normal business hours to avoid disrupting day-to-day operations for users.

Why This Topic is Gaining Importance Right Now

A key driver behind this development is the growing demand for auditability. Requirements such as NIS2 and DORA have already become established areas of focus, and they are now being joined by the need to assess AI management systems in accordance with the ISO 42001 standard. As a result, an increasing number of organisations need to demonstrate that their chatbots and voicebots are subject to regular security assessments and audits.

This is where the differences between the three approaches become particularly clear. Integrated guardrails are relatively limited in this area, as they often provide only restricted documentation and limited visibility into how decisions are made. Adaptive tools provide significantly more reporting and insight, although their capabilities remain dependent on the specific features and limitations of the solution being used. The managed penetesting service, by contrast, can be tailored much more flexibly – for example, whether a customer wants to test 10, 100, or 500 attack vectors – and therefore provides the most comprehensive and transparent evidence.

The three approaches also differ in terms of residual risk. Depending on their configuration, integrated guardrails alone are typically associated with a medium to high level of remaining risk. Adaptive tools can reduce this risk considerably by applying established enterprise-grade security controls in the background. Managed penetration testing provides the most realistic assessment because testing is performed against live systems using realistic attack scenarios and interactions, resulting in the lowest residual risk.

Conclusion: Defence in Depth Rather Than a Single Solution

Ultimately, the conclusion is that this is not an either/or decision. Voicebots should be protected through multiple layers: guardrails provide the first line of defence, adaptive tools add further protection, and penetration testing in real time assesses how resilient these security measures actually are.

This layered approach ensures that if one control fails, either the attack is prevented from progressing or the potential impact is significantly reduced.

Organisations that want to minimise residual risk as far as possible should therefore consider all three layers together rather than implementing individual measures in isolation. Companies that want to understand how secure their own voicebot really is can assess this through a managed penetration test provided by Damovo.