I'm responsible for rolling out Claude Enterprise across a mid-sized organization with a few hundred users. SSO and sensible default settings are already in place, but I'm struggling with how to govern plugins, MCP servers, skills, and hooks.
These features can appear to have broad permissions, and their actual execution behavior isn't always obvious. Allowing users to install anything they want seems like a serious security risk, but the controls I've found appear to support only a deny-by-default model with manually maintained allowlists. That would mean security has to approve and configure every new resource, while users can't safely experiment or develop integrations locally.
It feels like the choices are either allowing too much or blocking nearly everything. How are other organizations handling this in practice, especially across the different Claude clients and deployment options?
3 Answers
The management experience varies a lot depending on whether people are using the web app, desktop client, or coding tools. A setting or skill available in one client may not apply to another, and the product changes frequently enough that keeping policies current can become a full-time responsibility.
In practice, many teams start with deny-by-default controls and maintain a reviewed allowlist, while also putting most of their effort into data classification, access permissions, and controls around the connected systems. That doesn’t solve the product’s policy gaps, but it limits the damage when the integration layer itself is difficult to govern.
We’ve taken the strict approach and kept these features disabled by default. It’s not popular with users, but broad permissions combined with unclear execution paths are difficult to justify in a business environment. The explanation is basically that convenience features need a security review before they’re enabled.
That’s the position I’d prefer from a risk standpoint, but I’m worried about handling the constant requests for useful integrations. It feels like the administrator becomes the bottleneck for every new capability.
A useful way to think about this is to treat Claude integrations like a network tunnel. The integration determines what Claude attempts to do, but the strongest controls usually belong on the destination side rather than in Claude itself.
For example, with a source-control integration, configure the vendor connection and then restrict which repositories the integration can access or modify. Don’t rely on per-user controls inside Claude if the connector doesn’t provide that level of identity or authorization. Apply the real permissions through the connected service’s IAM, repository policies, network controls, and audit logs.
The same general approach applies to MCP servers, skills, and other extensions: constrain the systems they can reach and the actions those systems permit. Integrations where you can’t control the destination or the connection path are the ones I’d disable entirely.
The differences between clients are exactly what make this difficult. I can’t change our broader data-control policies, so I’m trying to work within the limited controls available in the Claude administration settings.