Create a Team Access Binding

Tasks

Grant a team access to one or more MCP servers by creating an Access Binding. For the access model this configures, see Team Access.

Create a binding

1. Go to Setup → Settings → Access Bindings → New Access Binding.

2. Fill in the binding. The editor has four sections:

   Section	Field	Description
   	Name	A unique identifier for the binding, e.g. platform-team-k8s. You can't rename a binding after you create it
   Applies to	Subjects	Teams, IdP groups, individual users, agents (trailing * glob allowed), or agent labels
   Models	Models	Optional. The models the binding grants, from the models your upstreams advertise, or a pattern such as claude-* — see Grant LLM models
   MCP tools	Per server	All tools, Selected tools, or None for each connected server, plus tool patterns — see Grant specific tools
   Advanced	Decision mode	Allow, Audit, Warn, Hold, or Deny. Hold uses the existing require-approval wire value — see Decision mode mapping
   Advanced	Toolsets	Read-only. The Toolsets the binding already references; their tools join the grant. Grant new tools under MCP tools
   Advanced	Servers for conditions and scopes	Optional. The servers where the binding's conditions and scopes apply. While the binding has no tool grant, each server listed also grants every tool. MCP tools doesn't change this list
   Advanced	Scopes	Optional. Narrows the allowed tool scopes for these subjects. Enforced at both token issuance and per tool call — a request whose scopes exceed the binding's allowed scopes is denied
   Advanced	Conditions	Optional CEL expressions, each with its own denial message, evaluated in addition to the decision mode
   Advanced	Input / output conditions	Optional CEL over the request arguments and the tool's response — violations always deny; see Control MCP tool access
   Advanced	Rate limits	Optional call-rate caps per user/agent/team — see Rate-limit MCP tools

3. Save. The binding takes effect immediately — the next token request or tool call from a member of the named teams is evaluated against it.

note

Scope narrowing applies to scope-bearing requests — the caller must present a scoped identity (e.g. a Cross-App Access / ID-JAG token). A binding's scopes narrow what its teams may request for the bound servers: a request whose requested/granted scopes aren't a subset of the binding's allowed scopes is denied at token issuance (invalid_grant) and re-checked per tool call. A binding with no scopes set places no scope restriction.

Verify

1. Have a member of a named team connect and confirm their client requests a token for a bound server successfully.
2. Have a member of a team that isn't named in any binding for that server attempt the same — confirm the request fails with invalid_grant.
3. Check Security Events for the successful call and confirm it shows the binding's binding_name.

Remove or narrow access

Edit a binding to add or remove teams and servers, or change its decision mode. Every edit is recorded in the binding's history, and you can restore an earlier revision. See Review and restore a binding change. The name is fixed after you create the binding. You can't delete a binding that a Workload Blueprint selects. Deleting a binding removes that grant — if no other binding covers a (team, server) pair afterward, the default of no access applies again immediately.

Troubleshooting

Symptom	Cause
Developer still gets invalid_grant after being added to a binding's team	Team membership is resolved from the identity token at issuance — the developer needs a fresh sign-in/token, not just updated IdP group membership, for the change to take effect
Binding has no visible effect on tool-level access	Check decisionMode — Audit and Warn allow the call through and only affect logging/messaging, they don't restrict anything
Scopes don't seem to restrict which tools are callable	Confirm the client presents a scoped identity (e.g. via XAA/ID-JAG) and that its requested/granted scopes are a subset of the binding's allowed scopes — narrowing only applies to scope-bearing requests. A binding with no scopes set applies no scope restriction

See also

• Team Access
• Policy Context