Tested as someone who cannot change it

Every hardening plan I write for a Claude organization ends with the same thing: a completed test log from a standard member account.

The configuration screen shows what the Owner intended to enforce. It does not prove what a member experiences.

Configuration is not evidence

Anthropic’s connector action restrictions are organization-wide on Team and Enterprise. Owners can set connector actions to always allow, needs approval or blocked, and individual users cannot widen the organization policy. That gives us a clear thing to test.

A settings page proves intent. The member test proves enforcement. Remote connectors work across Claude surfaces, so a meaningful control test uses the same real action from more than one surface and verifies that the organization ceiling follows it. The separate endpoint controls need their own tests too.

The tests

Run the tests as a standard member, not as an Owner or Admin. Use connectors and capabilities that are actually enabled in the test organization.

The Gmail test is valid because Anthropic’s current Google Workspace connector supports sending, replying to and forwarding email. If the organization policy blocks those actions, a failed send is evidence of the ceiling rather than evidence that Gmail has no send capability.

The log below is filled in as a completed example rather than left as a blank form. Each row is the test, what to do, and what should happen, and each result line ends with the verdict and the tester. JF is me; replace it with whoever ran the row.

1. 01 Blocked send, Cowork

   Ask Claude to reply to an email and send it, from Cowork.

   Result Send action denied by organization policy. Pass · Tester: JF

2. 02 Blocked send, claude.ai

   Repeat the same reply-and-send request in a normal browser conversation.

   Result Send action denied by organization policy. Pass · Tester: JF

3. 03 Blocked send, Claude Desktop chat

   Repeat the same reply-and-send request in Claude Desktop chat.

   Result Send action denied by organization policy. Pass · Tester: JF

4. 04 The productive path, Cowork

   Ask Claude to prepare the same reply as a Gmail draft without sending it.

   Result Draft created, nothing sent. Pass · Tester: JF

5. 05 Approval required, Cowork

   Run a harmless write operation on a connector tool configured as needs approval.

   Result Approval required according to organization policy. Pass · Tester: JF

6. 06 Blocked write, claude.ai

   Try to share or modify data through a connector action configured as blocked.

   Result Action denied. Pass · Tester: JF

7. 07 Reconnect, claude.ai

   Disconnect and reconnect the member’s own connector, then repeat the blocked send.

   Result Organization ceiling unchanged. Pass · Tester: JF

8. 08 Extension allowlist, Claude Desktop

   Try to install an extension that is not on the organization allowlist.

   Result Blocked by the allowlist. Pass · Tester: JF

9. 09 Local MCP, managed Claude Desktop

   Try to add or use a local development MCP server on a managed endpoint.

   Result Blocked or unavailable by managed policy. Pass · Tester: JF

10. 10 Personal login, managed Claude Desktop

    Try to sign in to Claude Desktop with a personal account.

    Result Rejected by forceLoginOrgUUID. Pass · Tester: JF

A verification log is evidence only after somebody has run it, which is why the example is completed and initialled rather than presented as a checklist to print.

Remote connector policy is organization-wide. A write action that is blocked at the organizational ceiling should not become available because the member changed surface. If one surface behaves differently, that is the finding.

The draft test matters just as much as blocking send. Hardening that removes the useful path teaches people to route around the control, so prove all three effective states: allowed, approval required, and blocked.

The reconnect test is there because the organization-wide action policy should remain the ceiling: the policy belongs to the organization, not to the member’s OAuth session.

The last three rows are not connector tests at all. They prove the controls outside the remote connector policy, and each one proves a different control plane.

Know what the test does not prove

Do not add a fake pass row claiming that Team blocks a personal Claude account in an unmanaged browser from connecting a corporate Gmail, Google Drive or Microsoft 365 identity.

Team does not have the Enterprise verified-domain connector restriction or Enterprise Tenant Restrictions. That path is a residual Team gap, and the Technical Note on the four paths around the ceiling documents it as one.

A good test log includes the limits of what was tested. It does not turn missing controls green for symmetry.

What the log is for

The completed log is evidence. A screenshot of an Owner configuration page shows intent. A test performed as a standard member shows outcome from the perspective of the population the control is supposed to constrain.

It also gives the monthly review a starting point.

Connector tools change. Product surfaces change. Write capabilities appear where a connector was previously read-only. An organization can change its policy. A source service can change its permissions.

Rerun the high-risk rows after a material connector change and as part of the periodic governance review. Do not rely on a static statement that the tenant was hardened once.

If the log has never been completed, the tenant has a configuration. It does not yet have a verified control.

Product note. Product features change frequently, so always check current features and documentation before acting on this note. It reflects behavior as reviewed in September 2026 and is a starting point rather than a configuration reference.

Explore this expertise: AI Platform Governance

All technical notes