Set the ceiling before Claude can act

Claude's organization controls are useful well before you get to fine-grained roles. The organization-wide connector policy sets the maximum permission a user can grant to a connector tool, and that ceiling is already a meaningful control on its own.

Owners on Team and Enterprise plans can limit which actions a connected service is allowed to take across the organization. Enterprise adds custom roles that narrow things further for particular groups, but the ceiling does not depend on having them.

The broader question of what an AI connector can reach, what the connected identity inherits and how read and write operations fail differently is covered elsewhere in these Technical Notes. This note is narrower. It is about the control the administrator actually has: how the organization ceiling behaves, what sits underneath it and where that boundary stops.

The organization policy is the ceiling

How Claude connector controls compose

Organization policy boundary

Maximum permission Organization-wide tool policy Team and Enterprise. Nothing below this can widen past it.

Optional narrowing Enterprise custom roles Present only on Enterprise, and only ever stricter. The ceiling does not depend on them.

Result Effective permission Personal approval choice where available, never looser than the ceiling.

Guidance, not enforcement Organization instructions Shapes how Claude is expected to behave inside the boundary. Removes no capability.

Outside this policy Locally run connector Not governed by the organization connector policy. Needs a separate control path.

Separate boundary Connected-system permissions Limits what the resulting action can actually reach.

At the organization level, individual connector tools can be restricted using three settings:

• Always allow
• Needs approval
• Blocked

The names are simple. Their composition is the part worth understanding.

Always allow permits the tool at the most permissive option available to the member. It does not by itself promise that every invocation happens without confirmation.

Needs approval keeps the tool available but removes the option to run it without confirmation. What remains to the member are the stricter choices.

Blocked means the tool cannot be used. Claude cannot see or call a tool that the effective connector policy blocks.

The useful security property is directionality.

The organization policy sets the maximum. Individual users cannot override it to gain more permission. Where personal approval choices are available, they can choose a stricter setting than the organization requires, never a looser one.

That turns the organization setting into an enforcement boundary rather than a recommended user preference.

Review the default for unconfigured tools

In the Claude organization settings reviewed in August 2026, there is a default restriction for tools that do not yet have a specific policy, including tools a connector adds later. Treat that default as part of the connector review rather than leaving it implicit.

Connectors change. A connector with ten tools today can gain another later without anybody revisiting the original implementation decision.

The default is not housekeeping. It is the policy for capabilities that do not exist yet.

Decide it explicitly. It is being decided either way.

The ceiling works without fine-grained roles

An organization with no custom roles at all still has a real connector control. The organization-wide policy applies across the organization, and users cannot widen past it.

The trade-off is scope, not whether the control works. Without custom roles, the same maximum applies broadly. With them, particular users or groups can be narrowed underneath that same maximum.

Lack of fine-grained user targeting is not the same thing as lack of governance. An organization can still decide centrally that a tool is allowed, gated behind approval, or blocked outright, and that decision holds.

Enterprise adds another layer

Enterprise changes the granularity of the control, not whether the organization has a control.

Claude Enterprise custom roles narrow connector access for particular users or groups beneath the organization policy.

The organization might set sharing a file externally to Needs approval, and a role might narrow that to Blocked for a team that should never do it at all. What no role can do is make the action more permissive than the organization allows.

The organization policy defines what can ever be allowed. Roles define who gets which subset underneath it.

Two implementation details matter when designing this.

First, role grants are additive. Where a member holds several applicable roles, the most permissive grant for each tool applies, and the organization ceiling is enforced on top of the result.

That means a second role cannot be used as a deny rule to claw back access another role grants. If something must never be permitted beyond a particular level, that restriction belongs in the organization ceiling, not in a role.

Second, built-in and custom roles do not compose the same way. Members with the User, Admin or Owner role take their permissions from that role directly, and members assigned to custom roles do not automatically inherit organization-enabled capabilities. Verify who a role policy actually applies to rather than assuming a restrictive custom role reaches everyone.

One seeding detail is worth checking on the day connector permissions are switched on: existing custom roles are seeded with the All connectors grant at Always allow, while a newly created role starts at Needs approval on every connector. The permissive default is the one attached to the roles you already have.

Organization-wide rules and guardrails

Connector permissions are not the only organization control, and it helps to keep three kinds apart.

Technical permission boundaries. Connector tool policies, capability toggles and blocked actions. These decide what is technically available at all.

Approval boundaries. Requiring confirmation before an action runs. These decide when a person has to be in the loop.

Organization instructions. Guidance Claude follows across conversations: how company information should be handled, what requires confirmation, escalation expectations, internal operating rules. Admins and above can set them on Team and Enterprise plans, and they take precedence over an individual's own instructions.

Permissions define what Claude can do. Organization instructions define how you expect Claude to behave within that boundary.

The distinction matters more than it sounds. An instruction saying customer information must not be sent externally is useful governance. A connector policy that blocks the external-send tool is enforcement.

Use both where they fit. Do not let the instruction stand in for the permission: instructions are guardrails, not a substitute for removing a capability that should not be available in the first place.

A permissive ceiling does not guarantee a permissive outcome

The organization policy defines a maximum. It does not oblige every Claude surface to offer the tool at that maximum.

Additional product or surface controls can narrow access further, so a configuration can be correct at the organization layer while a particular environment still behaves more restrictively.

This is the expected direction of composition: a lower layer can make the outcome stricter, never wider than the organization ceiling.

When troubleshooting connector behavior, distinguish between:

• the maximum the organization permits
• the effective permission on the surface where the user is working

They are not always the same thing.

Know where the ceiling stops

The organization connector policy does not cover every possible connector path.

Connectors a member runs locally on their own machine sit outside this policy and need a separate control path appropriate to the environment they run in.

That is not a reason to weaken the organization policy. It is a reason to avoid assuming that one control covers every way a tool can be connected.

The important question is not only:

What does our Claude connector policy block?

It is also:

Which connector paths does this policy actually govern?

Connector permission is still only one boundary

The organization ceiling controls which connector tool Claude is permitted to call. The connected system controls what the identity behind that call can actually reach.

Those are different controls.

If Claude is permitted to search files, the source system still determines which files the connected identity can see. If Claude is permitted to create or modify something, the source system still determines where that identity has write access.

A restrictive connector policy should not be used to justify an unnecessarily powerful account in the connected platform.

Design the connector policy for intent.

Design the target-system permissions for consequence.

What I would verify before enabling a connector

Before treating the configuration as complete, I want clear answers to these questions:

• What organization-wide ceiling applies to this tool?
• Is that global policy appropriate if it applies broadly to our users?
• Do we need different access for different teams?
• If so, does our plan support the role granularity that requires?
• What organization-wide instructions or operating rules should accompany the technical controls?
• Which requirements are only instructions, and which are technically enforced?
• What is the default for new or unconfigured tools?
• What controls exist in the connected platform itself?

Start with the organization-wide boundary. Add role granularity where the plan and the business requirement justify it.

The value of agentic tooling comes from allowing it to act. The control is knowing exactly where that ability stops.

A useful configuration is not one where Claude can do nothing. It is one where the allowed capability is intentional, the maximum is enforced centrally and anything outside that boundary requires another explicit decision.

Product note. Claude's connector, role and approval controls are moving quickly. This note reflects Anthropic's documented behavior as reviewed in August 2026 and should be revalidated against current documentation before it is used as a configuration reference.

Explore this expertise: AI Platform Governance

All technical notes