MCP Server
Administrative controls
What a workspace administrator can govern today, stated plainly, including what is not yet configurable, and the control that compensates for it.
Security reviews turn on this section rather than the last one, so it is written to be checked rather than reassuring. Where a control does not exist yet, it says so.
What you control today
| Control | Status |
|---|---|
| Authentication policy | availableInherited from your identity provider. A workspace on SAML/OIDC SSO authenticates MCP through its own IdP, so MFA, device posture and conditional access all apply. |
| Cutting off one person's access | availableRemove the workspace membership. Revo verifies it on every request against its own database, so the next MCP call fails outright. This is the only lever with an immediate guarantee, and it does not depend on the token expiring. Deactivating the user in your IdP is a useful second step, but it blocks future sign-ins and refreshes rather than the access token already in the client's hands. |
| Bounding what a person can reach | availableThrough their Revo role and the app's own visibility rules. MCP grants no access a user does not already have in the product. |
| Usage and cost visibility | availableWorkspace admins see per-teammate AI usage, which surfaces unusual MCP-driven activity. |
What is not configurable yet
These are genuine gaps, not omissions from this page. If any is a condition of approval, raise it with your Revo contact. Several are small changes on a design that already fails closed.
| Control | Status and compensating control |
|---|---|
| Disabling MCP workspace-wide | not yetAny member can connect their own assistant self-service; there is no admin switch to prevent it. Compensating control: the connection can reach only what that member can already reach, and their usage is visible to admins. |
| Requiring admin approval to connect | not yetConnection is self-service by design. |
| Restricting to read-only | not yetPermissions are derived from role and cannot be narrowed per workspace. A read-only pilot is not expressible today. Compensating control: no user-facing tool deletes data. |
| Disabling individual tools | not yetIncluding ask_revo, the one tool that acts autonomously and reaches integrations and the web. |
| Allow-listing approved AI clients | not yetClients register dynamically, so any MCP-capable client a user chooses can connect. Compensating control: the user authenticates interactively through your IdP each time, so an unapproved client cannot connect silently. |
| A customer-visible audit log | not yetTool calls are captured in Revo's internal application logging and monitoring, within the certified audit scope, but there is no exportable per-workspace log of who connected and which tools ran. Compensating control: writes flow through the same commands and events as the app, so their effects appear in the product's own history. |
| Excluding specific content from MCP | not yetThere is no sensitivity label that blocks a meeting from MCP specifically. Compensating control: private meetings stay private to their owner, and knowledge-graph results are visibility-filtered per user. |
| Seeing and revoking MCP connections | not yetThere is no screen listing who has connected an assistant, and no button to revoke one connection on its own, neither for the user nor for an admin. Compensating control: removing the workspace membership stops all of that person's access at the next request, which is stronger than revoking a single connection, if blunter. |
| A workspace-wide kill switch | not yetCompensating control: because authorization is recomputed per request from your own directory, suspending users in your IdP or removing memberships stops all their MCP access at the next call. That is the fastest lever available today, and it is immediate. |
If you are evaluating for an enterprise rollout
The honest summary: the security model is strong, the administrative surface is thin. Isolation, least privilege and credential handling are enforced in the platform and are not weakened by MCP. But the levers an administrator has are the platform's existing ones, roles, memberships and your IdP, rather than MCP-specific policy.
For a controlled pilot that works within today's constraints: scope it to a named group, give those users the minimum Revo role that covers the work, keep them in an SSO-enforced group so access follows your joiner-mover-leaver process, and review their usage through the admin usage report. Ask Revo directly about timelines for org-level disable, per-scope restriction and an exportable audit log.