Enterprise MCP Access Control: Scopes, Presets and Policies

Enterprise MCP access control means every agent identity has a policy that limits which tools it can see, which data classes those tools may touch, and whether it may take side-effecting actions. Good control is enforced at execution and at output, defaults to closed, and is managed per key rather than per team.

Start with identities, not tools

Access rules need something to attach to. In an agent setting the useful identities are usually one key per agent or integration, plus OAuth sign-in for human users who connect an assistant. The MCP specification includes an authorization framework built on OAuth for remote servers; BusinessMCP’s Enterprise page says its consent screen uses OAuth 2.1 with PKCE (S256) and exact-match redirect URIs.

One key per consumer matters more than it sounds. A reporting dashboard and an outbound email agent should never share a credential, because their risk is completely different. Separate keys also make revocation targeted. The security best practices article treats this as the first control to implement.

Data classes beat tool lists

Listing allowed tools one by one does not scale; new tools arrive constantly. A better model assigns each tool to the data classes it touches and writes policy against the classes. BusinessMCP’s access control documentation names these classes: revenue and financials, analytics and session behaviour, contact PII, company enrichment, CRM or config changes, email and audience sends, code writes, and connected-source reads such as Slack, Gmail, Drive and web. Its Enterprise page describes policies across 13 data classes.

The documented behaviour is worth noting because it shows what thorough enforcement looks like. Without the revenue class, revenue tools are blocked and revenue fields are also removed from other tools’ output. Disallowed tools are not advertised to the agent at all. Any field a policy does not permit shows as “[redacted]”.

Key takeaway: control both the call and the result. Blocking a tool but leaking its fields through a different tool is the classic gap.

Presets versus custom policies

Most organisations can start with presets. According to BusinessMCP’s documentation, every plan includes five: Read-only, No revenue, No PII, Analytics-only and No-send. Enterprise adds fully custom policies that combine any data classes with any “can act” settings. The Enterprise page’s limits table shows the tier difference as five presets on Business versus presets or custom rules on Enterprise.

Approach	Good for	Limitation
Preset such as Read-only	Dashboards, reporting agents	Cannot express unusual mixes
Preset such as No-send	Research agents that must never email	Coarse, applies to all sends
Custom policy	Agents that read revenue but not PII and may open pull requests	Needs design effort and review
Owner or admin full access	Humans who administer the workspace	Should be few and protected by 2FA

Note a documented default: governance is opt-in, and with no policy configured everything is full access, while owners and admins always have full access. That is a reasonable product choice, but it means “we have a platform” is not the same as “we have controls”. Someone must actually assign policies.

A worked example

Suppose three agents share one workspace.

1. Reporting agent. Needs analytics and revenue, never contact details, never actions. Assign a policy with those two classes and no “can act” permission.
2. Research agent. Reads company enrichment and connected web sources. Give it No-send so it cannot email even if instructed to.
3. Outreach agent. Drafts emails using contact data. It may propose sends, but sending is gated by approval so that a person confirms each one.

The approval step is the key. BusinessMCP documents that side-effecting tools, such as sending email, pushing audiences, opening pull requests and CRM writes, are gated by the policy’s “can act” flag, and sensitive actions appear as approvals in the owner’s dashboard. An external agent can propose an email, but a human must approve it. See the audit logging guide for what to record around those approvals.

Administrative controls around the policy

Policy is only as strong as the accounts that can change it. The Enterprise page lists enforced two-factor authentication and allowed sign-in domains per workspace, and storing platform API keys as SHA-256 hashes that are shown once. These are the controls that protect the controls. When comparing vendors, ask who can edit policies, whether edits are logged and whether keys can be scoped at creation.

Common mistakes

• Giving every agent an admin key because it was convenient during the pilot.
• Writing policy per tool and forgetting new tools default to allowed.
• Filtering the tool list but not the output.
• Treating the prompt as a control; instructions to the model are requests, not enforcement.
• Never reviewing which keys are still active.

Reviewing access regularly

Put a recurring review on the calendar: list keys, owners and policies, remove unused ones and compare what each agent can do with what it needs. The enterprise-ready checklist includes this. For a full view of how BusinessMCP packages custom policies, approvals and in-perimeter servers, read its Enterprise page and judge it against your own requirements.

Handling the awkward cases

Real deployments hit situations that clean diagrams skip. Three come up repeatedly.

Shared service accounts behind a tool. A connected source such as a mailbox or CRM is usually authorised once, by one person, and then used by many agents. The access policy on the agent side is what stops a research agent from reading everything that one account can reach. If your platform keeps the source token in a vault and resolves it server-side, the agent never holds it, which is the model BusinessMCP’s security guide describes. Without that, the effective permission of every agent equals the permission of whoever connected the source.

Temporary elevation. An analyst may need an agent to read contact data for one investigation. Resist editing the standing policy. Issue a separate, short-lived key with the wider scope, record why, and revoke it afterwards. The cost is a few minutes; the benefit is that the permanent keys stay narrow and the review stays simple.

Agents calling other agents. When one agent delegates to another, the permission of the chain should be no wider than the narrowest link. Today most platforms do not model delegation explicitly, so the safe habit is to give the delegate its own key with its own policy rather than letting it borrow the caller’s.

How to test that the policy works

Policies fail quietly. Write a short test plan and run it whenever a policy changes.

1. Connect with the restricted key and list tools. Confirm the forbidden ones are absent.
2. Call an allowed tool that touches a forbidden field. Confirm the field is removed or marked as redacted.
3. Try calling a forbidden tool by name anyway. Confirm it is rejected at execution.
4. Trigger a gated action and confirm it waits for approval instead of running.
5. Check the log shows the policy that governed each call.

If any step surprises you, the control is weaker than the documentation suggests. That is normal and fixable, but only if you look.