Botpress Breach: Why Bot Settings Can Expose Your API Keys
Botpress disclosed access to bot settings that can hold API keys. Learn why chat privacy and connected credentials require different recovery checks.
Botpress Breach: Why Bot Settings Can Expose Your API Keys
Botpress says an intruder read bot configurations that could contain connected-service credentials. That matters even without stolen chat history: a key can authorize spending or access elsewhere. Botpress reports no evidence of end-user conversation access and has notified affected workspace owners. The practical question is which credentials need revocation—not whether deleting a conversation fixes the problem. Read the disclosure.
By OpenVeil Editorial. Research cutoff: November 9, 2026. This is a source-based analysis, not an independent forensic investigation or a test of Botpress security.
What Is Confirmed
In its November 6 disclosure, Botpress describes an authentication-proxy flaw, internal-tool access, and an employee API credential with customer-workspace admin rights. On October 21, configurations in 16 workspaces were read; integration settings were changed in two others. Settings can hold AI-provider keys, messaging tokens and CRM credentials. Botpress says it fixed the proxy flaw that day and revoked the employee credential. It contacted affected owners with the relevant bots and integrations. Botpress's incident account.
What Is Still Unclear
The logs cannot establish which affected bots held valid credentials. Botpress therefore asks notified customers to treat those credentials as exposed. No evidence of conversation access is not proof that every possible downstream use has been ruled out. Botpress's stated limits.
Why Bot Settings Are More Than Harmless Metadata
An AI bot has at least two different kinds of valuable information: what people tell it and what it is allowed to do. Privacy discussions often concentrate on the first. Operational settings can encode the second.
Consider a hypothetical support bot connected to a model provider, a messaging channel and a customer database. Its transcript might contain a shipping question. Its configuration might contain the authority to consume paid inference, send messages or retrieve customer records. The exact reach depends on the permissions of each credential—not the friendly label on the bot.
That distinction changes the question an administrator should ask. “Were conversations taken?” is important, but incomplete. Add: “Could someone obtain the authority the bot uses outside this workspace?”
This is not an assertion that every integration token grants broad access. Some are tightly restricted; others are not. A useful assessment starts with actual issuer-side permissions and activity records rather than assuming that all keys are equivalent.
Botpress's authentication documentation illustrates why identity type matters. It distinguishes personal access tokens, which carry the user's access, from bot and integration keys with narrower API availability. Those documents describe ordinary authentication; they do not identify the exact token type stolen in this incident. Do not silently turn a general documentation example into a forensic finding.
The Overlooked Question: Who Can Administer Your Bot?
The distinctive trust boundary here is standing administrative membership. A support relationship is not just a help-desk conversation when the support identity can administer customer workspaces.
For any hosted AI platform, ask who can grant, exercise and remove that access. Does troubleshooting require an employee to remain a member indefinitely? Can support access be time-limited and approved for a specific task? Can an administrator inspect configuration without retrieving a saved credential's plaintext value?
These are evaluation questions, not claims about controls Botpress currently offers. A provider's answer should distinguish what exists now from a proposed hardening change.
For your own organization, review dormant collaborators and broad service identities too. Restricting vendor staff while leaving a former contractor's reusable administrator token active would leave a different route open. The goal is an inventory of authority, not a checklist that singles out only one category of person.
Our guide to checking an AI privacy claim explains the broader principle: identify the particular data, actor and boundary a promise actually covers.
A Three-Part Worksheet for Affected Integrations
Use one row for each credential implicated by your vendor notice. Record identifiers and owners, never the secret itself. The worksheet below is our analysis framework, not a Botpress incident log.
| Review point | Evidence to collect | What it helps establish |
|---|---|---|
| Workspace access | Relevant bot, integration, administrative identity and access window | Which configuration was in scope |
| Credential issuer | Key identifier, provider account, allowed actions and resources | What authority the credential carried elsewhere |
| Recovery result | Revocation time, replacement deployment, rejected old-key test and activity review | Whether the old authority has actually ended |
The first column prevents a vague “our chatbot was affected” conclusion. The second prevents a key rotation from being treated as merely a local settings change. The third prevents a successful bot response from becoming the only recovery evidence.
For example, a bot working with its replacement key proves that the new configuration functions. It does not, by itself, prove that the old key is invalid at the provider. Those are separate tests.
Likewise, a credential that could only spend inference credits calls for a different review from one that could read customer records. Do not assume the latter exposure from the former, or dismiss unexpected spending because no chat transcript was accessed.
What Should an Affected Workspace Owner Do?
Start with the vendor's direct notice and your own incident-response process. Do not publish tokens, customer records or full configuration exports in community threads while trying to get help.
- Identify the specific integrations. Match the notice to the correct workspace and bot. Assign a person responsible for each downstream service. Keep a timestamped record of the notice and changes in a restricted location.
- End the old credential's authority at its issuer. Removing a value from a bot configuration is not the same as revoking it at the service that accepts it. Coordinate replacement and revocation to contain exposure without accidentally interrupting critical workflows. If abuse is active, prioritize containment with the responsible service owner.
- Install the replacement with narrower permissions where supported. Prefer a dedicated credential for the integration rather than reusing a human administrator's general-purpose access. Confirm its actual scope and any spending controls in the issuing service.
- Check both success and rejection. Verify the intended integration works, then safely verify that the old credential is no longer accepted. Avoid making destructive or billable requests merely to test a key.
- Review the downstream account. Check available authentication, usage, billing and resource-access records for the relevant period. Preserve suspicious evidence and escalate to the provider. Empty or unavailable logs are an investigation limitation, not proof of no misuse.
These recommendations follow the distinction between creation, rotation, revocation and auditing in the OWASP Secrets Management Cheat Sheet. They are general defensive guidance, not a claim that we tested a particular Botpress recovery procedure.
If you did not receive a notice but remain concerned, contact the vendor through a known channel and confirm the relevant workspace. A search result or another customer's screenshot does not establish that your own bot was included.
Why Deleting Chats or Disabling Training Is a Different Control
Deleting a transcript addresses a content record. Disabling training addresses a use of content. Neither action inherently revokes a credential accepted by a separate service.
That is why it is useful to keep three questions separate:
- Where is conversation history retained?
- Which services process an active request?
- What continuing authority do saved connections grant?
A convincing answer to the first question cannot substitute for answers to the other two. For a different boundary involving operational records rather than bot configuration, see our WorkOS customer-data analysis.
For individuals who only need a writing or research assistant, the useful decision may be simpler: do you need to connect a privileged business account at all? Avoiding unnecessary delegation reduces the authority you must evaluate. It does not make a hosted chat session offline or eliminate provider processing.
Where OpenVeil Fits—and Where It Does Not
OpenVeil is an 18+ hosted AI workspace for chat, search, files, voice and creative media. Its documented privacy model keeps private chat history in your browser, without a server-side chat-history record, and does not use prompts, uploads or outputs to train foundation models.
Those are specific history and training boundaries. Active requests still require processing by OpenVeil and necessary providers; account and billing records are separate. Browser-local history can disappear when you clear browser data or change browsers. Read what browser-local history means and the privacy policy before relying on that model.
OpenVeil is not a secret manager, an incident-response service or a fix for the Botpress breach. It does not revoke credentials in other platforms, and it is not fully offline or anonymous. Do not paste a live API key into an AI chat to ask whether it was exposed.
If your separate goal is a hosted creative workspace with clearly scoped chat-history handling, try OpenVeil's ten-action, no-card preview using non-sensitive material. Paid plans start at $10 per month. That is a product choice for a particular privacy requirement—not a substitute for securing your existing integrations.
Frequently Asked Questions
Does deleting my Botpress chat history invalidate an API key?
Do not assume so. A connected service decides whether a credential remains valid. Check revocation with that issuer rather than relying on a local content-deletion action.
Is changing my login password enough?
Not necessarily. Passwords, API keys, integration tokens and active sessions can have different lifecycles. Identify the affected credential and follow the relevant service's recovery guidance instead of assuming one password reset invalidates every form of access.
Should I disconnect every AI integration?
Make that decision from the incident scope, the connection's permissions and your operational needs. Pause a risky connection when appropriate, but distinguish a documented exposure from a hypothetical one. Keep only the access the task genuinely requires.
Does browser-local AI history protect connected credentials?
Not by itself. Local history is a storage-location property. Credential protection depends on where secrets are stored, who can retrieve them and which service accepts them. A private hosted workspace and local model execution are also different concepts.
Bottom Line
Treat AI privacy and delegated authority as related but separate reviews. A bot's settings can matter as much as its transcript when they connect to other services. The useful recovery evidence is not simply “the bot works again”: it is a clear account of what was reachable, which old credentials stopped working and what downstream activity was checked.
Sources
- Botpress: November 2026 security incident disclosure — primary incident account and investigation limits.
- Botpress API authentication — ordinary token types and authorization context, not independent incident findings.
- OWASP Secrets Management Cheat Sheet — defensive lifecycle and audit guidance.
The worksheet and hypothetical support-bot example are editorial analysis. They are not additional observed victims, an exploitation demonstration or an assurance that every downstream system has been investigated.