Bubble MCP Security: Five Questions Outside the Manual, and What Stays Off After the First-Connection Checklist
The official Bubble MCP setup guide gets you through the first connection. It leaves five security questions open: preview tokens, API secrets, read auditing, database isolation, and global OAuth scope.
The official Bubble MCP manual covers onboarding and stops there. It tells you to configure https://mcp.bubble.io/mcp, set up OAuth and turn on Developer mode. It also reassures you that the agent cannot deploy to live or merge branches on its own. If you're building an MVP fast with no-code tools and vibe-coding, that's enough to connect an AI assistant to your editor and feel the productivity jump. Worth reading next: Why You Don't Need ai.
There's a gap between connecting the server and running it safely every day. On October 7, 2026, a public Bubble forum digest raised five security questions the manual leaves unanswered. Bubble staff answered in the comments. Some of their answers settled where the limits are. Others confirmed that a cautious solo builder should keep certain features locked down. Here's how I read them. Same topic: Bubble MCP server: Three Meanings.
1. Database Access: Data-Type Isolation vs. General Collaborator Rights
The documentation suggests fine-grained data control. It mentions tools such as grant_agent_data_access for specific data types. In the forum thread, Bubble staff clarified what that tool actually does. It gives the agent general collaborator data access. It does not set per-data-type permissions for the MCP agent.
| Name | What it is for | What it is not for |
|---|---|---|
| Documentation on database access | Fine-grained data control; tools such as grant_agent_data_access for specific data types |
— |
grant_agent_data_access (Bubble staff clarification) |
General collaborator data access for the agent | Per-data-type permissions for the MCP agent |
| Per-data-type MCP permissions | — | Not set by grant_agent_data_access |
If you're a non-technical founder testing an early product, the takeaway is simple. Don't put real customer records, credentials, or personal information in your development database. Every record the MCP tool reads goes straight into the connected AI provider's context window.
2. Preview and Impersonation Links: Long Lifetimes Without Revocation
The agent can generate preview links so it can inspect your app's views. That includes run-as-user sessions. Bubble staff said these links stay valid for about one hour until clicked. Once opened, the preview session can last up to a full day. Right now you can't revoke a preview link after it's generated. Bubble is also phasing out the deprecated impersonation token tool.
If you share AI workspaces or forward prompts, user preview links can leak sessions you never meant to share. Keep automated preview generation restricted during development.
3. Secrets and API Connector: Unchecked Headers in LLM Context
Most MVPs connect to external services through the Bubble API Connector. Bubble confirmed that the agent can read any parameter or header not marked as Private, using get_node. Values flagged as Private and plugin keys are redacted.
One missing checkbox can hand a live API key or auth header straight to the language model. Make sure every sensitive credential in your API Connector settings is set to Private.
4. Action Logs: Write Changelogs Without Read Forensics
When AI agents edit your workflows, you need to see what changed. Bubble said it is adjusting the editor changelog to capture MCP write actions better. Read operations by MCP aren't logged on Bubble's side at all. To track them, you have to check the logs in your AI provider's workspace.
There's another catch. If the agent deletes records with delete_thing in the development database, the standard editor Undo button won't bring them back. Take a manual savepoint of your branch before you give an MCP agent any structural task.
5. OAuth Scope: Full Account Access Without Per-App Boundaries
Right now, authorizing Bubble MCP through OAuth gives access to your whole Bubble account. There's no read-only mode and no per-app authorization scope yet. Bubble said it is looking at per-app configuration for future updates. The manual suggests naming the target app in your prompt. That helps, but a prompt doesn't limit what the agent can actually access. Same topic: Bubble MCP Account-Wide vs Per-App:.
If the account you connect owns several client apps or production systems, the agent could change the wrong app.
What Solo Builders Should Keep Disabled: A Safe-Operation Protocol
Until Bubble adds better admin guardrails for MCP, I'd stick to these four conservative rules to protect early-stage builds:
- Production and multi-app accounts: don't attach MCP to accounts that hold mission-critical client projects or live products. Test in an isolated account or a sandbox app.
- Live data in dev: fill the development database with mock data only.
- Unmarked API credentials: check every API Connector call and turn on the Private toggle for every private parameter.
- Unsaved work sessions: don't start a vibe-coding session with MCP until you've taken an editor savepoint.