Home Cloud Management Cloud Security Security Guidelines for cloud-native Chatbots

Security Guidelines for cloud-native Chatbots


Welcome to the era of digital transformation.

It’s the era of technology, easy communication, and well-informed consumers. In fact, this growing need for quick, easy and effective communication has resulted in – you guessed it – the rise of chatbots.

For Chatbots, it need not be foretold that they are going to be the cornerstones of customer engagements over the web. To list a few, they cater to needs like prompt customer support, helping with product FAQs, making reservations of cabs, hotels, etc. All of this has a direct impact on customer satisfaction and brings in stickiness to online branding mediums.

What’s the hype about Chatbots?

Chatbots are in the constant state of change as the AI frontier continues to grow in terms of improvement and development. They can certainly supplement your current human workforce, not necessarily replace them. However, here are some interesting facts and mind-boggling trends on Chatbot adoption in the coming years, which justifies these are spreading like fire in the forest:

  • Over 50% of customers expect a business to be open 24/7. This can only be achieved through ChatBots
  • By 2020, it is predicted that 85% of consumer interactions will be handled without a human agent implying the scale of ChatBot adoption
  • 80% of businesses are expected to have some sort of chatbot automation by 2020 in order to achieve speed, efficiency, and serviceability
  • Chatbots can save up to 30% in customer support costs

Albeit interesting, there are some serious concerns with respect to secure deployment and adoption of Chatbots.

Chatbot breaches that made headlines

There have been multiple security breaches due to the use of ChatBot. To enlist a few:

  1. A leading chain of department stores in the US reported data breach involving credit card information of thousands of their customers were exposed
  2. A major airline in the US also reported being affected by data breach where customer payment data was stolen away by the hackers.

The above two incidents occurred due to a third party Chatbot service.

Questions about Chatbots that everybody should ask

To build further upon this context allow me to state the incident that raised security concerns on our readiness to adopt this revolutionary medium of communication for internet transactions.

I was on this website researching about one of their offerings when a pop-up message from ‘The Bot’ caught my attention. It offered me all the help to research as well as select the best of the offerings on their site. After entering my queries, I was amazed at the quality of response from ‘The Bot’ which shortlisted some offers that exactly suited my requirement. While I chose not to push the offerings in the cart I ended up with numerous queries about the bot on the other side, such as:

  • What information did I just provide to the bot?
  • Was the response link with buying offers, shared by the bot, safe to click open?
  • I hope I did not fall prey to social engineering and shared my details; that may be of potential help if the bot has any malicious intents!
  • Wait, was that bot secure at all in the first place?

This made me research about the architecture of ChatBot, functionalities of each module and its security practices.

How Chatbot are categorized

I would typically categorize ChatBots as below and they both have the same architecture and security framework.

Enterprise Web Chatbot:

These are typically built on top of RPA (Robotic Process Automation) to cater to the automation needs of the organization. RPAs essentially handle the automation of the repeatable tasks and the Chatbot adds the human interaction & service feel to it. It helps in gathering variables required for executing the tasks. For e.g installation of common software on desktops, reset of passwords, etc.

Public Web Chatbots:

These are chatbots for websites, mobile apps and social platforms with the intention to improve engagement with the visitors and prospect customers.

Chatbot and the Cloud connection

Before I delve into the Chatbot security let me put the spotlight on Amazon Lex services.

Amazon Lex

Amazon Lex is a service is a fully managed service that allows integrating text and voice interface to your applications. Loaded with automatic speech recognition (ASR) and natural language understanding (NLU); it’s the best medium to offer a conversational experience for your users.

Since it’s a completely managed service there is no infra to manage and maintain which also means lesser vulnerabilities (no unpatched OS, no outdated firmware & no patching of IDE, etc). Stress-free, isn’t it?

Apart from being secure, it is highly cost-effective as; there is no upfront cost or a minimum fee for starting Lex. One is charged only for the voice or text requests that are made.

Amazon Lex supports integration with multiple AWS services like the AWS Lambda, AWS Comprehend, AWS Mobile Hub, CloudWatch, Amazon Dynamo DB, etc. This ensure that the Lex can be stitched together to serve multi scenarios viz; Conversational Chatbot that automates the password reset, Informational ChatBot for reading the news on request and capturing customer support requests, Application Bots for booking tickets, ordering food, etc.

Applications are numerous and AWS provides a host of services that can help you achieve a secure, fully manageable and scalable ChatBot.

The architecture of a Chatbot

I have explained the entire general architecture for a ChatBot and the security that ought to be implemented. I’d always prefer a fully managed serverless ChatBot service like Amazon Lex; instead of building something that runs within a run-time-environment on top of an OS all of which is managed by discrete stakeholders (mostly siloed ?).


There are some ChatBot security guidelines for the Developers as well as for its End-Users. I will cover these security guidelines into a two-part series.

Part 1: Security Guidelines for ChatBot Developers

End-to-End Encryption:

Communication channels are prone to eavesdropping and hence should be encrypted using standard protocols. The Chatbot endpoint hence should compulsorily use HTTPS for communication with the client application.

Amazon Lex uses the HTTPS protocol to communicate with your client application.

Data Protection

Utterances of every user are sensitive info and privy to them. Hence, it’s critical and a regulatory requirement to protect this data from leakage and tampering.

  1. Storing and Protecting the customer Utterances: Amazon Lex allows the developer to enable configurations such that the Bot user utterances are not stored at all. The default, however, is to store it for 15 days. For the data that is stored by Lex, it is encrypted at-rest and retained for 15 days(default). If a voice input is accepted by the bot then the data is stored indefinitely; it can be used by Lex for improving the bot’s ability to respond to user inputs.
  2. Destruction of Stored Utterances: A chatbot framework should ideally allow self-destruction of user’s sensitive information stored with it for whatsoever reasons. Amazon Lex provides the feature of ‘DeleteUtterences’ to delete any stored utterances.


Authenticating a communication channel is critical before the ChatBot prompts the user to write utterances that are sensitive and lead to potential data leak. Also, the ChatBot should not be allowed to access enterprise applications without an authentication (and it should be password-less role-based access)

AWS Cognito can be integrated with Amazon Lex for achieving a federated authentication and access mechanism. This ensures only authenticated user can perform actions that change values in your applications and its DB. The application will be connected to the DB using role-based access.

Session Timeouts

Any communication channel that involves the users share info and respond with utterances should be guarded with a session timeout. This ensures that idle sessions are not exploited by trespassers.

By default, Amazon Lex session duration is 5 minutes; but you can specify any duration between 0 and 1,440 minutes (24 hours).

That was a brief on security guidelines for developers and how Amazon Lex seamlessly offers the same. I strongly advocate the use of serverless and fully managed Amazon Lex; which offers loads of built-in security features and allows integration with tons of other AWS services. Thus helping us achieve a truly enterprise-grade ChatBot.

Security is a shared responsibility; hence the users are too expected to be cautious when engaging with automated communication channels. In the next part, I will cover the security practices for ChatBot End Users.

Follow the blog for Part 2.

Amitkumar Pandey
Amitkumar Pandey
Amitkumar holds 11 years of diverse experience in Solutioning and PreSales, Cloud Delivery, Project Transitioning, and Management. He is currently associated with Progressive Infotech Pvt Ltd as a Principal Consultant.


Cloud Management