Botpress Lost 39 Minutes. Its Customers Now Have to Assume Every Key Is Gone.

Botpress disclosed on November 6 that an unauthorized party used a compromised employee API credential to read bot configurations in 16 customer workspaces during a 39-minute window on October 21 between 07:44 and 08:23 UTC, and the company is now telling affected customers to treat every credential stored in those bots as exposed. Botpress CTO Michael Masson said the attacker entered through a flaw in the authentication proxy in front of internal tools, first probed on October 12, and that observed activity points to a single goal of obtaining AI usage to resell on AI black markets; Botpress fixed the flaw around 16:25 UTC on October 21, revoked the credential and blocked the attacker's accounts and network routes, and reported no evidence of access to source code, build pipelines, published packages or end-user conversations. The disclosure underscores that agent platforms function as credential vaults, since bot configurations hold third-party AI provider API keys, messaging channel tokens and CRM credentials.

An intruder read bot configurations in 16 customer workspaces, apparently to feed an AI black market. The lesson for every company running agents: an agent is only as safe as the secrets it holds, and a key is not rotated until the old one is dead. An AI agent is only as safe as the secrets it holds. And changing a key inside an agent platform achieves nothing if the old key still works at the provider: the only fix that counts is revocation at the source. That has been the position argued here for a long time. On November 6, Botpress published the clearest case study yet of why. Written with the help of AI tools; ideas, sources and final review by the author. In a disclosure signed by its CTO, Michael Masson, the agent-building platform explained that an unauthorized party got into some of its internal tools in October, obtained the API credential of a Botpress employee and used it to read the configuration of bots in 16 customer workspaces. The decisive part took 39 minutes: on the morning of October 21, between 07:44 and 08:23 UTC. Botpress is now asking the affected customers to treat every credential stored in those bots as exposed. That instruction deserves attention. It is not legal caution. It is an admission that, once an agent platform has been read, nobody can say which secrets are still safe. The timeline in Botpress’s own words is short and instructive. On October 12, someone began probing the authentication proxy that sits in front of several internal tools. That proxy had a flaw in how it validated sign-ins, which let the attacker enter with sessions that appeared to belong to Botpress staff. The company says it found no evidence that any employee account at its identity provider was compromised. Between October 13 and October 21, the attacker had access to internal tools and some connected systems. That access exposed customer account information and internal data, including data related to staff API credentials. One employee held admin access to a number of customer workspaces because they were a member of them. On October 21, the attacker used that employee’s credential, and the admin rights that came with it, to read bot configurations in 16 workspaces. Separately, weaknesses in the setup flow of some integrations allowed the attacker to change the settings of one integration in each of two other workspaces. Botpress fixed the authentication flaw at about 16:25 UTC the same day, revoked the employee credential and blocked the accounts and network routes linked to the attacker. The attacker kept trying to get back in; Botpress says every attempt it observed through November 3 was rejected. It also says it has no evidence of access to source code, build pipelines, published packages or the end-user conversations handled by customers’ bots. The sentence that matters most in the disclosure is a technical one. A bot’s configuration includes the settings of its installed integrations, and those settings can contain credentials for the third-party services connected to it: AI provider API keys, messaging channel tokens, CRM credentials and similar. That is what an agent is in practice. A useful agent answers customers on WhatsApp or Slack, looks up an account in the CRM, calls a model provider, maybe opens a ticket or updates a record. Each of those abilities is a secret stored somewhere. The more capable the agent, the longer its keyring. An agent platform that hosts thousands of such agents is no longer just a chatbot builder. It is a credential vault with a friendly interface on top. The motive confirms it. According to Botpress, everything observed points to a single goal: obtaining AI usage the attacker could resell on AI black markets. Before and during the intrusion, the attacker ran a large network of accounts on the platform to consume AI credits. No ransom demand was received and no customer data has been seen for sale. The target was not the conversations. It was the ability to spend someone else’s AI budget. Here is where many teams will get the response wrong. The natural reflex after a notice like this is to open the agent platform, paste a fresh key into the integration settings and move on. The bot keeps working, the dashboard looks clean, the ticket gets closed. But the key that was read is not stored only in that dashboard. It is valid at OpenAI, at the messaging provider, at the CRM vendor, until someone kills it there. If the old key is still active, the attacker who copied it does not care what the bot is now using. Replacing a secret in the tool is configuration. Revoking it at the issuer is remediation. Botpress’s logs illustrate the second problem. The company knows which bots were read, but cannot tell which of those bots held a valid credential at the time. That uncertainty is normal, and it is exactly why the only safe assumption is that every secret in a read configuration is live in someone else’s hands. The correct sequence is: create a new key at the provider, deploy it, revoke the old one at the provider, then check the provider’s usage logs for activity that does not match the agent’s normal pattern. Botpress is not the first agent product to show this pattern, and it will not be the last. In August 2025, Google Threat Intelligence Group reported that a threat actor it tracks as UNC6395 used stolen OAuth tokens from Salesloft Drift, an AI chat agent for sales, to export data from numerous corporate Salesforce instances. GTIG said it was aware of over 700 potentially impacted organizations. The attacker then searched the stolen data for more secrets, such as AWS access keys and Snowflake tokens. Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application on August 20, and Google later advised all Drift customers to treat any token stored in or connected to the platform as potentially compromised. Same shape: one integration layer, many downstream keys. The economics behind the Botpress attacker’s motive are documented too. In May 2024, the Sysdig Threat Research Team coined the term LLMjacking for attacks that use stolen cloud credentials to access hosted language models and resell that access while the victim pays the bill; it estimated the cost could exceed 46,000 dollars a day. In February 2026, Sysdig described the threat as a black-market reality, with stolen inference resold through underground gateways. A key to a model provider is now a liquid asset. Attackers know it, and they know where those keys are concentrated. The lesson is not “avoid agent platforms.” They are useful, and building everything in-house carries its own risks. The lesson is that buying an agent platform means delegating custody of secrets, and custody has to be managed like any other financial or legal exposure. That starts with ownership. In most companies, the person who connects an agent to the CRM is not the person responsible for the CRM’s security, and nobody keeps an inventory of which agent holds which key. When a notice like Botpress’s arrives, the first hours are lost reconstructing that map. Botpress itself points to the second issue: it is reviewing when its own employees should hold admin access to customer workspaces at all. Vendor staff with standing admin rights in customer environments turn one stolen employee credential into many breached customers. The third issue is scope. An agent that only needs to read tickets should not carry a key that can delete them. A bot that answers questions should not hold a model key with an unlimited budget. Narrow, capped, separately issued keys turn a breach from a disaster into a bill. Agents will hold more access every quarter, because that is what makes them useful. The companies that stay safe will be the ones that treat every agent as a keyholder and know how to take the keys back in minutes, at the source. Do you know which keys your agents hold today, and how fast you could revoke them at the source? If this was useful, follow Abbas Mistrah on Medium for more on AI strategy, agents and what actually works in production. Botpress Lost 39 Minutes. Its Customers Now Have to Assume Every Key Is Gone. https://pub.towardsai.net/botpress-lost-39-minutes-its-customers-now-have-to-assume-every-key-is-gone-caacb821a709 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.