I'm responsible for rolling out Claude Enterprise to a mid-sized organization with a few hundred users. SSO and the basic organization-wide settings are in place, but I'm struggling with governance for plugins, MCP servers, skills, and hooks.
These features can have fairly broad permissions, and it isn't always obvious when or how they execute. Letting users install arbitrary integrations seems risky from a security standpoint. The controls I've found appear to force an all-or-nothing approach: disable everything by default, then maintain a whitelist of approved resources through managed settings.
That creates an ongoing administrative burden whenever users need a new capability, and it also prevents them from developing or testing these tools locally. How are other organizations balancing security, user productivity, and the need to approve new integrations without either allowing everything or blocking everything?
4 Answers
Our policy is to keep plugins, MCP servers, skills, and hooks disabled. It’s much easier to explain and audit than allowing users to install arbitrary tools with unclear permissions.
The first thing to account for is that the controls can differ significantly depending on whether people are using the web app, desktop client, or command-line tools. Features enabled in one environment may not appear in another, and frequent product updates make the policy surface difficult to track.
Rather than trying to secure Claude in isolation, start by tightening the systems and data it can reach. For example, with a source-control integration, restrict the integration itself to approved repositories and apply your normal access controls there. The model may be able to make requests through the connector, but the connected service should still determine what those requests can actually access.
The same general idea applies to MCP servers, skills, and hooks: they influence what Claude attempts to do, while the systems on the other side of the connection should enforce the real boundaries. Integrations where you cannot control the destination or permissions are the ones I would disable.
The differences between the deployment types are a big part of the problem. For example, skills configured by an administrator aren’t necessarily available in every client. I agree that data controls matter, but I don’t have authority over those systems, so I’m trying to work with the limited controls available in the Claude administration layer.
Treat each integration like a network or identity boundary rather than trusting the tool because it is available inside Claude. Review what it can read, what it can modify, where credentials are stored, and whether the destination system logs and limits actions.
For approved tools, document an owner, permitted data types, required scopes, and a removal process. That won’t eliminate the maintenance burden, but it makes approvals repeatable instead of handling every request as a one-off exception.
What you’re describing is, unfortunately, the operating model many security teams end up with: deny by default and maintain an approved-resource list. It becomes a recurring governance task because every new capability needs review, testing, documentation, and a decision about which environments it can run in.
A practical compromise is to separate development from production. Let a small, isolated group test new integrations with non-sensitive data, then promote only reviewed tools into the managed allowlist. Keep the production policy restrictive, but give users a controlled sandbox so they aren’t forced to develop against a completely blocked environment.
I understand the security argument, but completely disabling them would create a lot of pushback here. I’m trying to find a process that gives users useful capabilities without turning every request into a manual exception.