Administer

Managing tool access

Control which tools each employee can reach, set once for everyone, layered per group, and overridden per person.

Managing tool access controls which connector tools each employee can reach from their AI client. It’s part of the Agent Handler for Employees setup: once your directory is connected through SCIM, you set the baseline every employee gets, layer extra access onto specific groups, and override individual people when you need to. You do all of it from the Provisioning → Manage access tab in the dashboard.

Granting tool access doesn’t connect anything on its own. Each employee still authenticates every connector (through Link or OAuth) before its tools work. Access decides what they’re allowed to reach; authentication decides whether the connection exists.

Dashboard role and tool access are separate

Every employee has two independent settings, and it’s worth keeping them straight before you configure anything:

  • Dashboard role is what someone can do inside the Agent Handler dashboard: Admin, Developer, Security, or Read-only. See Team and roles for what each grants.
  • Tool access is which connector tools their AI client can call.

These don’t constrain each other. An Admin can have no tool access, and a Read-only user can have every tool. Most pages of the Manage access tab let you set both at the same time, but they resolve on different axes.

How access adds up

Tool access is additive. An employee’s effective access is the union of four sources: the org-wide default, every group they belong to, their own per-user override, and any approved access requests. The most permissive setting wins, and for dashboard role they get the highest role they’re assigned (Admin is highest, Read-only lowest).

Every tier uses the same set of tool access modes:

  • All current and future tools: grants every tool in the org, including ones added later
  • Choose tools: grants specific Tool Packs and individual tools
  • No tools: grants nothing at this tier
  • Inherit (groups and users only): takes whatever the tier above already decided

Because tiers add together, a group set to No tools doesn’t take away access the org default or another group already granted. It just contributes nothing. To give someone no tools at all, the org default and every group they’re in have to withhold it, and you grant the exceptions through access requests.

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 Manage access → Default access → Configure. Pick a dashboard role and one of these tool access modes:

  • All current and future tools: all users get access to every tool by default
  • Choose tools: all users get access to specific tools by default
  • No tools: no tool access by default, group and individual access or requests can grant access

For Choose tools, attach Tool Packs (reusable bundles you maintain once) and any individual tools. 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 orgs where every employee should reach everything.

Group access

Group access grants additive permissions to all members of a group. Groups are your IdP groups, synced automatically through SCIM, so membership changes in Okta or Entra ID flow through without manual edits here. See Companies and Groups for how groups map in.

Open Manage access → Group access, pick a group, and choose Edit access. Set its dashboard role and tool access mode:

  • Inherit: access is determined by the org default
  • All current and future tools: access to every tool, overrides org defaults
  • Choose tools: add specific tools on top of the org default
  • No tools: no tool access from this group unless another group grants it

Map a job function to its tools once on the group, and every current and future member picks it up. 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-user overrides

Use a per-user override for exceptions, not as the main mechanism. Reach for it when one person needs something their groups and the default don’t cover, and prefer adjusting a group when the change applies to more than one person.

Open a user from the Manage access tab and configure their access:

  • Inherit: access is determined by groups and org
  • All current and future tools: access to every tool, overrides all
  • Choose tools: add specific tools on top of everything else
  • By request only: no tools by default, but the user can request individual tools

The user detail view shows Effective tool access: the combined result with each tool labeled by where it came from (organization default, a specific group, or the user override). Use it to see why someone has a tool before you change anything.

Access requests

When an employee’s AI client tries to use a tool they don’t have, they can request it with a reason. Requests land in Provisioning → Manage access → Requests, so you can run a tight default and grant the long tail on demand instead of provisioning everything up front.

For each pending request you can:

  • Approve it, permanently or with an expiry. The approved tools are added to that user’s effective access.
  • Deny it with an optional note.
  • Revoke a grant later if the need passes.

Every approval, denial, and revocation is recorded in the Audit Trail, alongside the reason the employee gave.

Next: build the bundles you assign here with Tool Packs.