Botpress Breach Reveals What AI Chatbots Can Expose Beyond Conversations

A security breach at AI chatbot platform Botpress has exposed a risk that can extend beyond the chatbot itself: the credentials stored in its connections to other business services.

Botpress says an unauthorised attacker accessed internal company tools and used an employee’s API credential to read bot configurations in 16 customer workspaces. Those configurations can contain API keys and access tokens for AI providers, messaging platforms and customer relationship management (CRM) systems.

The company has not established that those third-party credentials were valid or used to access the services they connect to. It has also reported no evidence that the attacker accessed end-user conversations. But the incident shows why chatbot integrations and the secrets stored in their settings need to be treated as part of an organisation’s wider security.

In a disclosure published on 6 November, Botpress CTO Michael Masson said the activity began on 12 October 2026, when someone started probing an authentication proxy protecting several internal tools.

An authentication proxy acts as a checkpoint in front of systems that should only be available to authorised staff. It checks whether a person or session is permitted to enter before allowing access. Botpress said a flaw in the proxy’s sign-in validation allowed the attacker to enter using sessions that appeared to belong to company employees.

Botpress said it found no evidence that an employee’s account with its identity provider had been compromised. The disclosure does not explain the precise technical method used to bypass the proxy, so it is not possible to establish how the weakness worked in more detail.

Between 13 and 21 October, the attacker had access to internal tools and some of the systems connected to them. Botpress said this provided visibility into customer account information and internal data, including information related to employee API credentials.

The next stage involved an employee credential that carried administrator access to a number of customer workspaces because the employee was a member of those workspaces. Between 07:44 and 08:23 UTC on 21 October, the attacker used that credential to read bot configurations in 16 workspaces.

This was not the same as gaining confirmed access to 16 customers’ external accounts. The activity Botpress specifically identified was the reading of bot configurations inside those workspaces. Separately, the attacker exploited weaknesses in the setup process for some integrations to change one integration setting in each of two other workspaces.

The distinction matters because a chatbot’s configuration can contain more than the settings needed to make its conversation interface work. When a business connects a bot to an AI provider, messaging channel or CRM, it may need to supply a credential that allows the integration to communicate with that service.

These credentials can include AI-provider API keys, messaging-channel tokens and CRM access details. An API key acts like a digital pass: an application presents it to a service to prove that it is authorised to make requests. Depending on the permissions attached to the key, it may allow an application to use AI models, send messages or interact with business records.

That makes configuration data sensitive. Someone who can read it may be able to see credentials that were never intended to be public. If a credential is valid and has sufficient permissions, another person could potentially use it to access the connected service. The actual reach would depend on the credential’s scope, restrictions and whether it remained active.

That is a possible consequence of credential exposure, not an outcome Botpress has confirmed in this incident. The company said its logs could not establish exactly which affected bots contained valid credentials at the time. It therefore asked the owners of the affected workspaces to treat every credential stored in the affected bots as exposed.

Botpress has not said that the attacker successfully used customer AI-provider keys, messaging tokens or CRM credentials. Nor has it reported confirmed access to those external services. The employee API credential used to read the Botpress workspaces should also not be confused with the separate customer credentials that may have been stored inside bot configurations.

The company said it fixed the authentication weakness at approximately 16:25 UTC on 21 October, rotated the proxy secret and revoked the employee credential used in the intrusion. It also blocked accounts, workspaces and network routes associated with the attacker, hardened its network entry rules, restricted and restarted affected internal tools, and reversed changes made to internal settings.

Botpress said it strengthened the way integration configurations are stored and began rotating internal credentials found in files the attacker had read. It is also changing the bot API so stored credentials cannot be reached in the same way, while reviewing staff access to internal tools and permissions, including when employees should have administrator access to customer workspaces.

The attacker continued trying to regain access through other routes and newly created platform accounts, according to Botpress. The company said the attempts it observed through 3 November were rejected.

Botpress believes the attacker’s main objective was to obtain AI usage that could be resold on underground markets. It said the attacker had operated a large network of accounts to consume AI credits and that much of the activity inside its systems appeared aimed at keeping those accounts running. This is the company’s assessment of the motive, rather than an independently established finding.

The company also said it had received no ransom demand and had seen no evidence that customer data was published or offered for sale. It reported no evidence that end-user conversations were accessed, or that its source code, build pipelines or published software packages were changed. These are findings from Botpress’s investigation; they should not be read as proof that every possible form of access was impossible.

For customers directly contacted by Botpress, the immediate priority is to follow the instructions and affected-bot lists supplied by the company. They should identify the integrations involved, revoke and replace credentials stored in the affected configurations, and check that replacement keys have only the permissions needed for their tasks.

They should also review activity logs for the connected services. Unexpected API requests, unusual AI usage, unfamiliar messages, changes to CRM records or unexplained billing can help identify whether a credential has been misused. Any suspicious activity should be raised with the relevant service provider.

Changing a Botpress account password alone would not replace a separate API key or messaging token stored in a bot’s integration settings. Those credentials need to be managed and rotated at the services that issued them.

Businesses that have not been contacted should not assume that their bots were accessed. Botpress says it has no evidence that the bots or configurations of customers it did not contact were read or changed. The disclosure does not establish that every Botpress customer was affected.

The wider lesson is not that chatbot platforms are inherently unsafe. It is that integrations can give a chatbot access to services beyond its own platform, and the credentials that make those connections work deserve the same protection as other business secrets.

Organisations should keep an inventory of the services each bot can reach, use separate credentials where possible, and limit each one to the minimum access required. A chatbot that only needs to send support messages should not hold a key with broad access to an entire customer database. This principle, known as least privilege, reduces the damage a stolen credential can cause.

The OWASP Secrets Management guidance recommends restricting who can access secrets, assigning them minimum necessary privileges, and making them revocable and manageable throughout their lifecycle. Businesses should also monitor how integrations use their credentials and have a clear process for replacing them if exposure is suspected.

Botpress’s disclosure does not show that the attacker used customer integration credentials to break into other services. It does show why the contents of a chatbot configuration matter. In connected systems, the security of the bot is only one part of the picture; the keys it holds can matter just as much.

How we checked this: Secritic reviewed Botpress’s original disclosure, its API authentication documentation and OWASP’s secrets management guidance. We also reviewed Unite.AI’s report, which largely summarises Botpress’s disclosure rather than independently verifying the incident. The timeline, affected workspaces, attacker motive and findings about customer data are attributed to Botpress. The company has not established which potentially exposed credentials were valid or whether they were used against connected services. Secritic has not independently examined internal logs or interviewed affected customers.