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
Great question but no not in this way. However I think weâre talking about different things.
In this case I would be using the user licence only for an integration so it feels like Iâm paying for a specific data connection. Thatâs not really fair or rational itâs just psychology of the âpain of payingâ.
On the other hand, if you were to release a bunch of new features (scoped API keys), and raise the licence fee a little because âwe have kept the same price for last 5 years and now the product is way more powerfulâ then I probably end up paying the same or more in $ but it feels far easier to swallow.
But if you mean specifically for AI Agents then yes capped / metered usage is OK.
For me itâs easier to follow if there are âcreditsâ specifically for AI usage and automation steps. And there is an amount of included value in each licence tier. Then Iâd like more clarity in the UI which things are consuming the credits so I can manage it by changing models per task or making steps more efficient. Centralised management as well as per run / agent / action.
We donât want to sneak a price increase in by bundling it with some feature releases. Rather, I was thinking of a couple of different cases:
a customer wants to use Fibery with multiple âagentsâ each with their own set of credentials and permissions (which are a subset of the human userâs permissions). These agents might use API or MCP to make changes, but either way, they operate semi-independently of human interaction, potentially each making multiple calls to the workspace (in parallel). In effect, the person can now have their own little team of AI-agents doing work for them.
a customer wants to use Fibery but wants each call to the workspace to be scoped specifically to the needs of the action, i.e. a workspace search that should be limited to certain non-sensitive dbs, or a cleanup action which is forbidden from making configuration changes to certain dbs and/or entity updates within certain dbs.
The question of what to charge for licences arises according to what limits are placed on these cases. Intuitively, the first case seems to me one where it would be fair to charge per agent, assuming the agents are going to be subject to independent limits on resource usage. The second case could be thought of as granular variations on the âarchitect-userâ mode toggle (scope limiting on a case-by-case basis) and thus need not incur additional licence costs, provided the limits on resource usage are applied in aggregate.
Anyway, these are just some thoughts I had, and nothing is defined yet, so obviously happy to hear input from the community as a whole. Thereâs so much happening/changing at the moment wrt AI that itâs not clear what the new paradigm for pricing will be, and we havenât made any concrete plans.
), or is this currently an intentional limitation for Member accounts with Architect rights?
