Per-Team Tool Access

Some teams shouldn't see every tool a vendor exposes. The gateway lets you set a per-team allowlist for each connected vendor — a Tier 1 helpdesk team can be scoped to a small set of safe read-and-update tools, while your engineering team keeps full access to the same vendor.

Overview

Every organization can already restrict which vendor tools are callable through an organization-level allowlist (Settings → Tool Access). Per-team tool access layers on top of that: each team can further narrow which tools its members can call, on a vendor-by-vendor basis.

The two scopes combine as an intersection: a team member can call a tool only if both the org allowlist and the team allowlist permit it. The org-level allowlist sets the ceiling; the team-level allowlist is a focused cut beneath it.

Note: a team allowlist narrows access — it never grants a tool the org allowlist already blocks. Least-privilege by design.

When you'd use this

• Tier 1 helpdesk scope. Allow your support team to triage tickets in Autotask or HaloPSA but not to delete contracts or modify billing data.
• Read-only auditors. Restrict a finance or audit team to the reporting / search tools of a vendor without exposing write operations.
• Onboarding sandbox. Give new technicians a focused tool set for their first weeks — expand it as they ramp.
• Compliance-sensitive vendors. Some vendors (e.g., security or identity tools) have tools you only want senior engineers calling. Scope the bulk of users away from the sensitive tools without disconnecting the vendor.

Prerequisites

• You're an org admin — tool access is an admin-managed setting.
• Your organization has at least one team created (Settings → Teams).
• The team has at least one vendor connection granted via Team Connections.

Step 1: Open a Team's Tool Access

From the Settings dashboard, go to Teams. Each team card shows its name, members, server-access checkboxes, and a row of action buttons. Click Tool Access on the team you want to scope.

Don't see the Tool Access button? Confirm the team has at least one vendor connection (Team Connections page) — the Tool Access editor only lists vendors the team can already reach.

Step 2: Pick a Vendor

The Tool Access editor lists every vendor this team has access to. Each vendor is a collapsible row — click the row to expand it and load the vendor's discovered tools.

When you expand a vendor for the first time, the gateway discovers its tools live from the vendor API — so the list always reflects what's currently available, not a stale snapshot.

Step 3: Choose an Allowlist Shape

Each vendor panel shows one of two states:

• Inherits org defaults (all N tools) — no team-level allowlist exists yet. Every box is checked. The team can call whatever the org allowlist permits for this vendor.
• Allowed tools (X of Y) — a team allowlist is in effect. Only the checked tools are callable by this team's members for this vendor.

To restrict a team, uncheck the tools you don't want them to call and click Save. To return a team to inheriting the org defaults, click Reset to inherit — the team allowlist is cleared and the panel returns to the inherit state.

Tip: ticking every checkbox and saving is the same as clearing the allowlist — the team will inherit the org defaults again. Use Reset to inherit for clarity.

Step 4: Review the Audit Row

Once a team has a restriction in place, the panel shows a one-line audit row: “Last changed by {name} on {date}”. The name is the admin who most recently saved an allowlist for this team/vendor pair, and the date is when that save happened.

Use the audit row to answer the obvious question after a tool stops working for a team member: who last changed this, and when?

How precedence works

Per-team tool access composes with the existing scopes the gateway already maintains:

1. Org allowlist — the outermost ceiling. Anything the org allowlist blocks is blocked everywhere, regardless of team settings.
2. Team allowlist — a narrowing cut beneath the org ceiling. A team member can call a tool only if their team's allowlist (or its inherited org defaults) permits it.
3. Personal connections — if a member uses their own personal credentials for a vendor, the request is scoped against the org allowlist directly (no team narrowing). Team allowlists only apply when the request is using team-shared credentials.

In short: the team allowlist filters what team-shared vendor traffic can do; it never blocks a member from using their own personal credentials at full org-scope.

Common questions

My team member says they can't see tool X — what changed?

Three things to check, in order:

1. Open the team's Tool Access editor and confirm tool X is checked in the vendor's panel. If it's unchecked, the team is restricted and won't see X.
2. Confirm the org-level Tool Access (Settings → Tool Access) also allows tool X. An org-level block overrides any team setting.
3. Confirm the team member is calling tools using team credentials (the default when no personal credentials are connected for that vendor). Personal credentials route through the org allowlist directly, not the team allowlist.

Can a member be on more than one team?

Not in v1. Each member belongs to one team at a time, which keeps the scope rules unambiguous — a tool call is always evaluated against exactly one team allowlist plus the org allowlist. Multi-team membership is on the roadmap.

What happens to existing teams when I first set up per-team tool access?

Nothing changes by default. Every team starts in the Inherits org defaults state for every vendor — same behavior as before the feature shipped. The feature only takes effect when an admin explicitly creates a restriction.

Does this work for personal connections?

No — personal-credential traffic isn't team-scoped (see How precedence works). If you need to restrict an individual rather than a team, ask that user to switch to team-shared credentials so the team allowlist applies.

Next Steps

• Teams & Organizations — create teams, invite members, and manage team credentials
• Gateway setup guide — configure Claude to use the gateway and the connected vendors
• Security — how credentials, authentication, and access controls fit together