Groups and access
Groups and access is the answer to “who can reach what.” A Group carries both halves of an employee’s access: the Connectors and Tool Packs their AI client can call, and the routing policy, approved models, and budget their model traffic runs under. Groups come from your identity provider, synced by SCIM, so membership changes in Okta or Entra ID flow through without an edit here.
You configure it from Provisioning: an organization-wide baseline on the Sync tab, per-Group settings on each Group’s detail page, and per-employee exceptions on the Employees tab.
Granting access does not connect anything on its own. Each employee still authenticates every Connector themselves, over OAuth, before its tools work. Access decides what they are allowed to reach; authentication decides whether the connection exists.
Dashboard role and employee access are separate
Every employee has two independent settings, and it is worth keeping them straight before you configure anything.
- Dashboard role is what someone can do inside the Workforce dashboard. See Team and roles
- Access is what their AI client can reach: tools, and the models behind their routing policy
These do not constrain each other. An admin can have no tool access, and someone with no dashboard access at all can have every tool.
How access adds up
Tool access is additive. An employee’s effective access is the union of four sources: the organization default, every Group they belong to, their own per-employee grants, and any approved access requests. The most permissive setting wins, and for dashboard role they get the highest role they are assigned.
Every tier uses the same set of modes:
Because tiers add together, a Group set to No tools does not take away access the default or another Group already granted. It contributes nothing. To leave someone with no tools at all, the organization default and every Group they are in have to withhold it, and you grant the exceptions through access requests.
Models resolve on two different rules. The routing policy is a single policy rather than a union: a Group either has its own policy or falls back to the organization default, and the Group’s page says which. The approved-models list does union, the same way tool access does, so one Group left unrestricted leaves its members unrestricted no matter how narrow their other Groups are. Budgets nest, so the first limit exhausted blocks the request.
Default access
Default access is the baseline every provisioned employee receives. Set it restrictively and grant up from there, rather than opening everything and clawing back.
Open Provisioning → Sync → Default access → Configure. Pick a dashboard role, then one of the three tool access modes. Under Choose tools, attach Tool Packs (reusable bundles you maintain once) and any individual tools from the picker.
A small Choose tools baseline, or No tools with everything granted through Groups, keeps the blast radius of the default tight. All current and future tools is the least work but the broadest grant, so reserve it for organizations where every employee should reach everything. The dialog warns you that the change affects every user, because it does.
Group access
Open a Group from the Groups tab. Three tabs carry everything the Group decides:
Routing and models names the policy the Group’s traffic runs under, badged Group policy when the Group has its own and Organization default when it falls back. A Group on the default is still routed. See Routing for how a policy chooses a model.
Approved models is the allowlist the Group’s members can reach. Left unset it reads “Any model in the catalog, including ones added later”, and it accepts a whole vendor as well as single models. Approving nothing is not the same as leaving it unset: an empty list denies every model to the Group.
Connectors and Tool Packs are the tool half. Granting a Tool Pack to a Group is the move to reach for: map a job function to its tools once, and every current and future member picks it up. Editing either one puts the Group into Choose tools, since a Group that inherits or grants everything has no list of its own to hold.
Allowed skills shows what the Group’s agents can load, badged by where each skill came from: Merge-managed, everyone in your organization, or this Group.
Budget is empty until you set one, and no budget means unlimited spend rather than zero. See Budgets for how the scopes nest.
When someone belongs to more than one Group, they get the most permissive tool access across all of them and the highest dashboard role.
Per-employee grants
Use a per-employee grant for exceptions, not as the main mechanism. Reach for it when one person needs something their Groups and the default do not cover, and prefer adjusting a Group when the change applies to more than one person.
Open an employee from the Employees tab and go to Access. The page shows their effective access as resolved server-side, so it cannot disagree with what their client sees:
- Connectors with the tools each one carries, and whether the employee has authenticated it yet
- Skills they can load, with the scope each came from
- A line naming everywhere the access came from: the Groups by name, plus your organization default, a direct grant, or an approved request
Add connector grants every tool on one Connector to that one employee. They still have to authenticate it themselves, so the grant shows as Not connected until they do.
An employee already set to all tools or no tools cannot be granted a Connector this way. Writing a grant would move them to Choose tools, which from all tools is a revocation, so the dialog refuses instead of performing one behind an “Add connector” label. Adjust the Group or the default for those employees.
When someone asks for something they do not have
When an employee’s AI client calls a tool they lack, the call fails and surfaces as an access request. That is what lets you run a tight default and grant the long tail on demand instead of provisioning everything up front. Approve, deny, or expire requests from Requests.
Next steps
Sync employees and Groups from Okta, Entra ID, OneLogin, or JumpCloud
Build the bundles you assign to a Group once and maintain in one place
Choose the policy a Group’s model traffic runs under
Cap what a Group can spend, and see what happens when it runs out
Review what employees asked for and grant it with or without an expiry