We ran into an AI governance/security issue while trying to use MCP together with sensitive databases.
Scenario:
We have a separate Finance Space and databases inside containing sensetive financial information.
Problem 1
If AI is enabled on the Workspace level and the account is an Admin, then AI potentially gets access to all databases — including financial ones. In many companies, management/security teams would ask to disable AI entirely because of this.
We thought about the following workaround:
Disable AI for entire Workspace
Keep Admin accounts “clean” for user management and sensitive databases
Create separate Member accounts
Give those Member accounts Architect access to all non-financial databases
Connect MCP only to those Member accounts
This would allow:
AI/MCP to work with operational databases
while keeping financial data isolated
Since MCP inherits account permissions, this seemed like a very good architecture for enterprise usage.
Current limitation
The issue is that currently Member accounts cannot connect MCP.
So the question is:
has anyone found a good solution for this?
or alternatively, would it make sense to allow Admins to explicitly grant MCP access permission to trusted Member accounts?
For example:
“Allow this Member account to use MCP”
while still respecting its existing workspace/database permissions
This should not be the case. It ought to be possible for an MCP client to connect to Fibery using whatever user credentials are used for authentication.
Thanks, Chris!
I may have missed something with a Member account then. I’ll check this again on our side.If it works with regular Member credentials and respects that user’s permissions, then it should fully solve our use case.
Good call I’ve been getting more worried about this over the last few weeks as the Dunning Kruger effect wears off just a little bit.
After the McKinsey/Lilli and Vercel/Roblox incidents I read a little more and reviewed a custom integration.
I guess I already knew some of this and did some good hygiene stuff like kept keys private, env variables etc but the token exists and is more likely compromised.
Here is one way to put it:
Fibery token is god-mode on the workspace.
Fibery tokens are user-scoped, not service-scoped. The bridge needs five DBs and currently has read/write on the entire workspace. Compromise = full workspace exposure. Fix: create a dedicated user in Fibery, restrict permissions to the five DBs, generate that user’s token. Document the user.
What are the alternatives now? I can only think of:
Pay for additional user just to generate keys with appropriate (limited) access. Still read/write but at least limited to dbs
Find an existing user with access matches what I need, get them to generate key and then hope I don’t change that users permissions in the future
Our current workaround is to separate accounts by purpose.
The idea is:
keep a dedicated Admin account only for workspace administration, user management, sensitive databases, etc.
do not generate API keys from this Admin account
create separate Member accounts for integrations / automation / MCP
give those Member accounts access only to the databases they actually need
generate API keys only from those limited Member accounts
This way, if an integration token is compromised, the exposure is limited to the databases that user can access, instead of the entire workspace.
For AI/MCP use cases, we are also considering disabling Fibery AI at the workspace level and using external AI through MCP connected with limited Member accounts, so sensitive areas like Finance stay isolated.
Yes
It does mean additional paid accounts/subscriptions, but we currently see it as the price for better isolation and peace of mind regarding sensitive data and integrations.
And if the number of these accounts stays relatively small, the overhead is still manageable — for example:
1 dedicated Admin account
1 integration/API account for general automations
1 separate account for finance-related integrations
We tried implementing the approach I described above, but ran into another limitation .
It seems that only Admin accounts can create and save Automation Rules in databases, while Member accounts — even with Architect permissions on the Space — cannot.
Maybe we missed some setting, but intuitively it feels logical that if you trust someone with Architect permissions for a Space, they should also be able to create/manage automation rules inside that Space.
Are we misunderstanding something here (or didn’t find in settings ), or is this currently an intentional limitation for Member accounts with Architect rights?
Nope. Architects can create automations.
There is a limitation that only Admins can create script actions in rules, but otherwise Architects have free rein.
Maybe it would make sense to add at least a separate permission toggle for Script Actions?
For example, in our case we have junior and middle automation engineers. If we already grant them Architect access to a specific Space, we are effectively already trusting them to build automations there — including script-based ones (which, realistically, are often generated with ChatGPT assistance anyway).
Right now this limitation makes automation responsibilities much harder to delegate without giving full Admin access and theay are too limited in their actions (for example with webhooks [it is a basic crutial element for automation engineer] or another types of actions).
I just went through our automations and buttons, and in our case roughly 98% of them use scripts in some form .
So it really feels like having a workspace-level toggle to allow Script Actions specifically for Member accounts with Architect permissions would be very valuable.
Especially because Architects are already trusted to design and manage systems inside their Spaces — that is essentially their role.
At the moment, the built-in automation actions are intentionally very minimal, but because of that, scripts become almost mandatory very quickly even for relatively basic workflows or workaround solutions .
Automation scripts can effectively do things that normally require Admin level access, and for that reason we don’t allow them to be created by Members.
This is unlikely to change soon (we have it as something to think about, but no concrete plans).
It is certainly not our intention that no-code actions are minimal, quite the reverse. If there are use cases that come up often that can only be achieved with scripting, then we should look at working out how to make them available via no-code actions.
Feel free to tell us what’s missing here:
I don’t imagine this will (could) happen, since it would be equivalent to a toggle which allows Architects to have Admin powers
), or is this currently an intentional limitation for Member accounts with Architect rights?
