MCP Governance, User Roles and Permissions — Why It Matters for Enterprise

The hidden problem with most MCP setups

The Model Context Protocol opened a clean lane for AI agents to talk to real systems. The first wave of MCP servers ships as CLI binaries: install on a developer laptop, point Claude Desktop at it, done. That works for a single power user.

It does not work for an enterprise.

The moment more than one person inside a company needs MCP, three governance questions show up at once:

1. Who can use which connector?
2. What can each user do once connected (read? write? delete?)
3. Where does the audit trail live?

CLI-based MCP servers answer "everyone with the binary" / "anything the API can do" / "stdout, gone tomorrow". For a regulated business, that's a hard stop.

This is the gap AnythingMCP is built to close.

What governance means in an MCP context

In a classical SaaS, governance means users, groups, roles, permissions and an audit log. The same primitives apply to MCP, but they get one extra dimension: the tool.

An MCP server exposes a list of tools to the AI client. Each tool is a discrete capability — list_invoices, create_quote, delete_account. Without per-tool access control, granting "the CRM connector" to a user means granting every tool the connector exposes. That's the equivalent of giving an intern root SSH because they need to tail a log.

AnythingMCP treats four layers as first-class:

Every invocation is checked against all four, then logged.

The AnythingMCP governance model

Users and SSO

You can create users manually from the dashboard, or — and this is what enterprise customers actually do — wire your existing identity provider:

• SAML 2.0 for Okta, Azure AD, OneLogin, Ping, Auth0, Keycloak
• SCIM 2.0 for automatic provisioning and de-provisioning (when someone leaves the company, their MCP access disappears with their AD account, not three weeks later when ops gets around to it)
• Group → role mapping: AD group eng-platform automatically becomes role developer in AnythingMCP

No separate password to rotate, no shadow user list to keep in sync.

Roles

A role is a named bundle of permissions. AnythingMCP ships with sensible defaults — admin, developer, viewer — and lets you define your own.

A role definition looks like this conceptually:

role: finance
description: Finance team — read invoices everywhere, post in DATEV
connectors:
  - slug: datev
    tools:
      list_clients: read
      list_invoices: read
      create_booking: write
      delete_booking: off
  - slug: weclapp
    tools:
      list_invoices: read
      list_orders: read
  - slug: sap-erp
    tools:
      "*": off    # explicitly denied

The wildcard "*" matters: when you add a new tool to the SAP connector later, the finance role inherits off automatically — fail-closed instead of fail-open.

Per-connector access

The most common enterprise pattern: separate connectors by team boundary.

• Sales sees the CRM.
• Finance sees the ERP and accounting.
• Engineering sees production databases (read-only).
• Customer support sees the ticketing system.

Each team's AI agent — Claude, ChatGPT, Copilot, doesn't matter — only sees the tools their role allows. A salesperson asking ChatGPT to "delete the customer record" gets a clean denial from the gateway, not a 500 from SAP after the action already half-completed.

Per-tool permissions

This is the granularity CLI servers can't match.

A single MCP connector for Salesforce might expose 30+ tools: list_accounts, get_opportunity, create_opportunity, update_opportunity, delete_opportunity, list_leads, … For each, AnythingMCP supports three modes:

• read — the tool is callable and returns data, but mutations are filtered out
• write — the tool is fully callable
• off — the tool is hidden from the agent entirely (it doesn't even appear in the MCP tools/list response)

"Hidden" is the important bit. A model can't be jailbroken into calling a tool it doesn't know exists. By trimming the tool catalog per role, you reduce the attack surface to the minimum each user actually needs.

Audit log

Every tool invocation writes a row: who, when, which tool, which connector, with which arguments, what was returned (or what error). The log lives in your PostgreSQL — not in our cloud, not in a third party's S3 — and is queryable like any other table.

For regulated industries (banking, healthcare, public sector) this is what makes MCP usable at all. You can answer "did anyone read patient record 1234 last quarter" in one SQL query.

Why this is impossible with CLI-only MCP servers

The MCP ecosystem is full of single-purpose CLI servers — mcp-server-postgres, mcp-server-github, etc. They're great for personal use. They are structurally incapable of enterprise governance for four reasons:

1. No user concept. A CLI binary runs as the OS user who invoked it. There is no "Mario" vs "Anna" — there's just whoami. Two people sharing the same Claude Desktop install share the same MCP identity, by design.

2. No per-tool scoping. If the CLI exposes query_database, every user with the binary can call it with any SQL. You can't restrict it to SELECT only, or to specific tables, without forking the binary.

3. No central audit. Each binary logs to its own stdout. There's no place to ask "show me every MCP call made by the company last week".

4. No deprovisioning. When someone leaves, you have to track down every laptop with the binary installed and pull the credentials. In practice, nobody does this.

These aren't bugs in CLI servers — they're inherent to the architecture. A binary running on a developer machine has no concept of organizational identity.

Why hosted SaaS gateways have the opposite problem

The other obvious answer is "use a hosted MCP gateway SaaS". This solves the governance problem but introduces a worse one: your production credentials now live in a third party.

For a German GmbH or US regulated entity, this typically fails:

• Compliance — GDPR, BDSG, HIPAA, SOX all complicate (or forbid) handing service account credentials to a third party
• Blast radius — if the SaaS is breached, every customer's connected production systems are exposed at once
• Vendor lock-in — credentials, audit logs, role definitions, all live in a system you don't control

AnythingMCP is self-hosted by design. The gateway runs in your VPC, your Kubernetes cluster, your Hetzner box, your laptop — wherever you want. Credentials never leave your perimeter. The audit log lives in your database. Governance policies are versioned in your git repo if you want.

You get the governance of a hosted gateway with the trust posture of a self-hosted binary.

Why this matters for enterprises specifically

Three patterns we see repeatedly with enterprise buyers:

Pattern 1 — the security review gate

A pilot starts in IT or innovation. The moment the project moves to production, security review kicks in and asks:

• Can we revoke access for a specific user?
• Can we prove who called which tool?
• Where are the credentials stored, and who can decrypt them?

CLI servers fail all three. AnythingMCP answers each with a screenshot from the dashboard.

Pattern 2 — the legal/compliance gate

Legal asks: "If a regulator subpoenas us about an AI-driven decision, can we produce the call trail?"

The answer needs to be yes, with timestamps, user identity, and the full tool arguments. AnythingMCP's audit log is structured exactly for this — every invocation is a row with a timestamp, user, connector, tool, args, response status. Exporting it as CSV for legal is a one-line query.

Pattern 3 — the cross-team gate

Once one team has MCP working, three more teams want it. Without governance, each team either:

• Gets their own CLI install (loss of central oversight)
• Shares one install with no isolation (one team's mistake breaks another's data)

AnythingMCP lets a single instance serve all teams safely — sales sees only CRM, finance sees only ERP, eng sees only the metrics DB. Each team's AI client gets a different /mcp URL with its own scoped tool catalog.

A practical setup, end-to-end

Here's what a typical enterprise rollout looks like in AnythingMCP, step by step:

1. Deploy the gateway in your infrastructure (Docker, Helm, Railway, DigitalOcean — your call). Takes about 60 seconds.

2. Wire SSO. Point Okta or Azure AD at the gateway's SAML endpoint. Map your AD groups to AnythingMCP roles.

3. Add connectors. From the dashboard, point AnythingMCP at your APIs (OpenAPI URL, WSDL, database connection string). It generates the MCP tool catalog automatically.

4. Define roles. For each role, pick which connectors and which tools they can call (read / write / off). Wildcards default to off, so adding a new tool later never accidentally grants access.

5. Distribute the MCP endpoint to users. Each user's Claude / ChatGPT / Copilot client gets the same gateway URL — AnythingMCP returns the scoped tool catalog based on the authenticated user's role.

6. Monitor via the audit log. Every invocation lives in your Postgres; build a Metabase dashboard on top of it in an afternoon.

TL;DR — why AnythingMCP for governance

If governance is on your AI roadmap and self-hosted is non-negotiable — AnythingMCP is the only option that gives you both.

Getting started

You can try the governance model on AnythingMCP Cloud (7-day free trial, no credit card) or self-host the open-source build with a single command. Both ship the same RBAC engine.

→ Start free on Cloud → Self-host on GitHub → Talk to the team about enterprise rollouts