Permissions and grants

A permission check sits in front of the connectors. It decides whether the person making the request may use a connector, and it records the decision. This page explains why this layer is needed, what it decides on, and where you maintain the grants.

Why this layer is needed

If connectors are attached without a permission layer of their own, you can usually only define whether someone may use connectors at all, not which ones. Anyone who may use MCP then sees every attached system, or none.

For a tool like a weather lookup that does not matter. For an ERP it does: “accounting may see invoices, but not salaries” cannot be expressed at that level. The permission check closes exactly this gap.

What the permission check does

• A check before the call. A tool call only reaches the connector if the person making the request has been granted access to it. Otherwise they get a plain text message in the chat that points them at the admin. The chat carries on normally, there is no crash.
• A per-person tool list. Anyone without a grant for a connector is not offered its tools in the first place.
• A log of every call. Every decision is written down immutably, denials included. How long these entries are kept is defined in your own deletion policy, see Data protection and retention.
• Deny when in doubt. If a decision remains unclear, access is denied rather than allowed.
• The connector does not learn who is asking. The identity is needed for the decision and is not passed on to the connector.

The path of a request

The levels of a grant

Grants can be set for individual people, for roles, and for groups, and there is a default rule per connector on top of that. Where statements contradict each other, the resolution is deliberately restrictive. That is intentional: a security boundary must not be liftable just because someone is additionally in a harmless group.

Required step: set the default rule before granting access

The first thing to do after creating a connector is the default rule: set the connector’s default rule to denied, then deliberately grant access to the roles, groups and people who need the connector.

That way it is defined from the first second who can see behind the connector, and access is a deliberate decision rather than a side effect. Put this step on your acceptance checklist.

Besides the connector level, a grant can also be applied to individual tools.

Cut your connectors so that the connector level is enough

In day to day work, control at connector level carries most cases; it is also the more robust boundary. So plan your connectors accordingly: better two narrow connectors, each with its own service account, than one with many tools, half of which would have to be blocked. Connector patterns shows what that looks like.

Where you maintain the grants

Default rules, grants for roles and groups, and exceptions for individual people are maintained in the admin panel. The log of tool calls lives there as well and can be exported for your records. You can also work the other way round, starting from a single person and following which connectors are open to them.

Which view sits where and how it is operated is described in the guide that ships with your instance.

What the permission check does not do

• It does not replace the permissions in the source system. A service account with permissions that are too broad remains a risk, even with a check in front of it. Draw the data boundary in the source system, not in the prompt.
• It does not filter arguments and it does not filter content. A tool that accepts a free form query language cannot sensibly be restricted to “invoices only”. Prefer connectors with separate tools or with a read only mode.
• It is not the only boundary. With connectors that work with the permissions of the individual person, the target system itself draws the authoritative boundary, see connector patterns.