Skip to content

CONCEPT Cited by 1 source

Business-group authorization gating

Definition

Business-group authorization gating is the access-control pattern of restricting a service's effective user population at session-establishment time by checking a business-group membership claim extracted from the user's identity token. Users outside the allowlist cannot open a session, regardless of whether they could network-reach the service.

The key move: narrow access before the session opens, based on organisational-role claims, not per-request ACL checks.

Canonical wiki statement (Pinterest, 2026-03-19)

"Since some MCP servers can execute queries against sensitive internal data systems (like the Presto MCP server), we implemented business-group-based access gating. Rather than granting access to all authenticated Pinterest employees and contractors, some servers will: (1) Extract business group membership from the user's JWT token (2) Validate that the user belongs to an authorized group before accepting the connection (the list of approved groups is set during the initial review stage) (3) Selectively enable capabilities only for users whose roles require data access." (Source: sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest)

And:

"At Pinterest, this means that even though the Presto MCP server is technically reachable from broad surfaces like our LLM web chat interface, only a specific set of approved business groups (for example, Ads, Finance, or specific infra teams) can establish a session and run the higher-privilege tools. Turning on a powerful, data-heavy MCP server in a popular surface therefore doesn't silently expand who can see sensitive data."

The problem it solves

Wide-surface × data-heavy-tool is a blast-radius problem. If a data-heavy MCP server is reachable from a popular surface (say, the organisation-wide chat LLM), every employee becomes a potential ingress path for prompt injection + inadvertent data-leaks + social-engineering to query sensitive tables.

Two bad responses:

  • Hide the server from the popular surface. Gates legitimate use behind surface-switching friction.
  • Trust every authenticated employee. Widens the effective user population by ~10-100× beyond what's needed.

Business-group gating threads the needle: the server is reachable from the popular surface, but only users whose role requires the data can open a session. The popular surface stays general-purpose; the sensitive tool stays narrow.

Three implementation steps

  1. Claim extraction. The user's JWT carries a business-group membership claim (from the org's identity provider — LDAP groups, HR system, etc.).
  2. Session-establishment validation. Server-side policy validates the claim against the approved-groups allowlist set during review. Unapproved users get a connection refused; they don't get to issue any tool calls.
  3. Capability subsetting. Some tools may be enabled only for a narrower subset inside the approved set — e.g. schema-browse for all approved groups, table-query for a subset.

The allowlist is set during security review, not hand-coded per-deployment. This ties the access policy to the governance artefact.

  • patterns/jwt-tenant-claim-extraction — same JWT-claim-extraction machinery, different purpose: tenancy isolates data along a tenant axis; business-group gating narrows access along an organisational-role axis. Composable — a multi-tenant SaaS with internal business-group gating would use both.
  • concepts/fine-grained-authorization — business-group gating is one shape of coarse-grained session authorization; FGA typically means per-resource + per-action decisions at each request. The two compose: session-level business-group gating reduces the population FGA must evaluate requests for.
  • concepts/attribute-based-access-control (ABAC) — business-group-as-attribute is a degenerate 1-attribute case of ABAC. ABAC generalises to multi-attribute policies (role × department × geography × time × …).

Why "at session establishment" is the load-bearing phrase

Per-request ACL checks on a sensitive-tool server still leak "you can reach this server" to unauthorized users. Session-establishment gating means:

  • Unauthorized users get a connection refusal as the first signal. No tool inventory leaks. No partial-capability discovery.
  • The registry API ("Is this user allowed to use server X?") can answer No before an agent even tries to connect.
  • The client-facing UI can hide the server from unauthorized users entirely.

Seen in

Last updated · 319 distilled / 1,201 read