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 Operations → Access Bindings → Add binding.

2. Fill in the binding fields:

   Field	Description
   Name	A unique identifier for the binding, e.g. platform-team-k8s
   Teams	One or more IdP teams (groups) this binding applies to
   Servers	One or more MCP servers this binding covers
   Scopes	Optional. Narrows the allowed tool scopes for these teams on these servers. Enforced at both token issuance and per tool call — a request whose scopes exceed the binding's allowed scopes is denied
   Decision mode	Allow, Audit, Warn, RequireApproval, or Deny — see Decision mode mapping
   Conditions	Optional CEL expressions, each with its own denial message, evaluated in addition to the decision mode

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 the Audit Log 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. 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