In the threat-model work (#160) we discussed whether to explicitly document, at least in v1.0.0 that the mcp does not support multi tenancy. I.e. set the expectation that the only intended deployment option is that each user deploys their own mcp server with their own solr credentials, meaning the user understands that all and any action that is allowed by that user in solr-backend (admin permissions etc) will also be available to the mcp.
By formally documenting this (as already drafted as undecided in the threat model in 7ec9c34), we will avoid a ton of claimed vulnerability reports claiming that the mcp server allows too much or is insecure in multi tenancy setups.
In a later version, we can consider supporting multi tenancy.
In the threat-model work (#160) we discussed whether to explicitly document, at least in v1.0.0 that the mcp does not support multi tenancy. I.e. set the expectation that the only intended deployment option is that each user deploys their own mcp server with their own solr credentials, meaning the user understands that all and any action that is allowed by that user in solr-backend (admin permissions etc) will also be available to the mcp.
By formally documenting this (as already drafted as undecided in the threat model in 7ec9c34), we will avoid a ton of claimed vulnerability reports claiming that the mcp server allows too much or is insecure in multi tenancy setups.
In a later version, we can consider supporting multi tenancy.