durin
Sign up
Recipes

Scope access by team

Give different teams access to different tools. Engineering gets GitHub, support gets Jira, marketing gets Slack.

Before you configure scope

Use an administrator account and decide which system owns group membership. Prepare the intended people and connections, and identify a reviewed read for each installation. This recipe uses Engineering, Support, and Marketing as example group names; substitute your actual teams.

A group name is not an access rule by itself. You must assign the connection to the group. Also review any existing unscoped connections, because an installation with no team restriction remains organization-wide.

The pattern

Create teams that map to your organizational groups, then assign connections and policies per team. Personal connection visibility includes connections assigned to any of the member’s teams and connections with no team restriction. Administrators can inspect all installations; using one still requires team access and the other authorization checks.

Example setup

Scope three connections to three teams.

  1. In Teams, use Create group for Engineering, Support, and Marketing.
  2. Add members to each team.
  3. Create a GitHub connection and assign it to the Engineering team.
  4. Create a Jira connection and assign it to the Support team.
  5. Create a Slack connection and assign it to the Marketing team.
  6. Each team can only access their assigned connection through Durin.

Test the boundaries rather than the group names

After assigning the connections, test as intended members from each group. Administrator visibility in the installation directory does not prove a member’s effective access.

  1. Check that an Engineering member can use the reviewed GitHub read after completing personal authorization.
  2. Check that a Support-only member cannot use the Engineering-scoped installation.
  3. Check the Support and Marketing installations with their corresponding identities.
  4. Inspect the activity for each supported test and compare the recorded decision with the expected scope.

Handle people who belong to more than one team

If someone belongs to Engineering and Support, membership in either assigned team can satisfy a connection’s team scope. That person may therefore use both scoped installations, subject to credentials, reviewed resources, and policy checks.

Team policy restrictions are evaluated as well. A denial is not cancelled by joining another group. Review all of the person’s memberships when an action remains blocked or when access continues after removal from a single team.

Keep the setup accurate as teams change

When someone moves roles, change membership at its authoritative source and repeat the affected read checks. For a local group, use Durin’s group controls; for a directory-managed group, update the identity provider.

Try Durin with your MCP workflow.

Create an account to connect a client, route governed MCP requests, and review decisions with your admins.

Create an account

Production connections use provider setup and trust review.