Get started

Connect your identity provider, map Groups to tools and models, then hand employees their connection details

This is the setup path for governing your own employees. You configure which tools and models each Group can reach; employees point the AI client they already use at Workforce and sign in through SSO. Work through it once, in order, and the last step is the only one your employees see.

Your identity provider stays the source of truth for who exists and who belongs to what. Workforce maps those Groups to the tools and models their members can call. SCIM keeps the two in sync: add someone to the Sales group in Okta and they get what Sales has, with no separate step on your end.

If the AI user is your customer rather than your employee, you want Building an agent instead.

What you are setting up

  • Identity provisioned through your identity provider by SCIM, so employees are added and removed automatically
  • Tool and model access assigned to Groups, controlling what each team can reach
  • One MCP endpoint for tools, and a Gateway base URL and key for models
  • Logging active, with exportable records for compliance reviews

Setup

1

Enable SCIM and set default access

Open Provisioning → Sync in the Workforce dashboard and complete both of these before you touch your identity provider:

  1. Generate a SCIM token and copy the base URL alongside it, following SCIM provisioning. You paste both into your identity provider in the next step.
  2. Set Default access. This is what an employee can reach before they are assigned to a Group. Leave it empty and those employees see no tools in their AI client, which is the right starting point for most organizations. See Groups and access.
2

Configure SCIM in your identity provider

In Okta, Azure AD, Google Workspace, or another SCIM provider, configure the Workforce SCIM application. All three of these happen in the same session:

  1. Enter the SCIM endpoint and token from the previous step.
  2. Assign employees to the application. Workforce creates their records as they come through.
  3. Push the Groups you will use for access: your existing Sales, Engineering, and Finance groups, or whatever maps to roles in your organization.

Sync timing varies by provider. Okta is near real time, while Azure AD runs on an approximately 40-minute default cycle.

3

Map Groups to tools and models

Group access is set in two places. On Provisioning → Sync, the Group access table lists every Group your identity provider pushed; Edit access on a row sets:

  • Dashboard role: what members can do inside the Workforce dashboard.
  • Tool access: no tools, every tool, or a set you choose from Tool Packs and individual tools. Whatever you assign is what members can call from their AI client.

Then open Provisioning → Groups, pick a Group, and use its own tabs:

  • Resources: the routing policy and approved models members reach through Gateway, plus the Connectors, Tool Packs, and skills granted to them.
  • Budget: an optional spend cap for the Group, enforced before any vendor is called.

Settings apply to everyone in the Group, and an employee in more than one Group gets the most permissive access across all of them. Groups and access covers how default access, Group access, and individual overrides layer together.

4

Hand employees their connection details

Tools and models are separate connections, and an employee can have one or both. Tools are one MCP endpoint plus an SSO sign-in. Models are a base URL and a key in place of the provider key the client used before.

On a fleet you manage, the desktop client writes both connections on the machine and the employee configures nothing. Otherwise send them Connect employee AI clients, which has the exact configuration for each client. Choose a rollout path compares the two.

What admins control

  • Group-based access. Change a Group’s Tool Pack and every member’s access updates on the next call.
  • Direct assignment. Override access for one person when their Groups do not fit.
  • Token lifecycle. Access tokens expire after an hour and refresh tokens rotate. Revoke individual tokens from the dashboard.
  • Logs. Every tool call is recorded with employee, tool, arguments, and result, exportable for SOC 2, ISO 27001, and other audit requirements.
  • Deprovisioning. Remove an employee from your identity provider, or from the Group that grants their access, and their tokens are revoked immediately.

What employees see

The first time an employee connects, they sign in through your identity provider and get a consent screen listing the tools their Group has been granted. After that the AI client re-authenticates on its own.

Ask the assistant for something outside that set and the call fails, then the ask appears in Requests. You approve it, decline it, or widen the Group.

Common issues

  • Employee provisioned in your identity provider but not visible in Workforce. The SCIM sync may not have run yet. Okta is near real time; Azure AD defaults to an approximately 40-minute cycle. Check your provider’s provisioning log.
  • Employee can sign in, but the AI client shows no tools. Their Groups are not mapped to a Tool Pack. Open Provisioning → Sync, find the Group, and use Edit access. If they are not in a Group yet, check Default access too.
  • 403 mid-conversation. The client re-authorizes on its own. If the tool is outside the employee’s allowed set, the request is waiting for you in Requests.
  • Token will not refresh. Refresh tokens are revoked on deprovisioning. Confirm the employee is still active in your identity provider.

Next

Test what a Group can actually reach before you roll it out, in the Playground.