---
title: "Administrative controls"
description: "What an administrator controls on each server, and where that control lives in the console."
canonical: https://past.dev/docs/mcp/admin-controls
last-updated: 2026-10-09
---
# Administrative controls

> What an administrator controls on each server, and where that control lives in the console.

Product: past.dev MCP Server. Source: https://past.dev/docs/mcp/admin-controls

The two servers are administered differently. The account server is on for every organization and bounded by each person's role. The end-user server is off until someone enables it on a project, and everything about it is a console setting.

### What you control today

| Control | Status |
| --- | --- |
| Turning the end-user server on and off | **available** **Build › MCP server**, per project. Disabling it fails every install closed rather than routing it elsewhere. The account server has no such switch: see the next table. |
| Deciding which of your users may connect | **available** A rule over traits on the project's identity connection. It is evaluated at sign-in, at every refresh and on every tool call, so a group change at your provider takes effect without anyone touching the console. |
| Restricting the end-user server to read-only | **available** The project's write toggle. Turning it off refuses `remember` on existing tokens and drops the tool from every client on its next tool listing. |
| Authentication policy | **available** The account server inherits the console's hosted login, so the policies enforced there apply. The end-user server uses your own identity provider, so your policies apply and past.dev never holds your users' passwords. |
| Cutting off one person's access | **available** For a member, remove the organization membership: the next account call fails, and every account MCP session that person holds ends. For one of your users, change the trait their access depends on, or revoke their access link. |
| Bounding what a person can reach | **available** Through the platform role and project reach for a member, and through audiences for one of your users. MCP grants no access the caller does not already hold. |
| Seeing what an assistant did | **available** Every account tool call is written to the organization's request log with method `MCP`, the tool name as its path, the member as its caller and the client it came from. **Settings › MCP** reads those rows as Recent activity. A refused call is a row too, with its error code. |
| Revoking one MCP connection | **available** For one of your users, revoke the access link or sign the client out. For a member, removing the membership ends every session. A per-connection revoke screen for members is in the next table. |

### If you are evaluating for an enterprise rollout

Both servers use the platform's existing isolation, least-privilege and credential controls. Administrators manage member access through roles and memberships, and end-user access through the identity provider and the traits it maps.

For a controlled pilot, enable the end-user server on one project, set its access rule to a single group at your provider, and leave the write toggle off. Ask your past.dev contact about any control this page does not list.