How it works

The path one request takes through Workforce, and the objects it passes on the way

An employee’s AI client makes two kinds of request through Workforce. A tool call reaches a company system through a Connector. A model request reaches a model provider through Gateway. Both carry the employee’s identity, and both are decided against the same directory, the same Groups, and the same rules. Read this before you configure anything, so you know which stage each setting acts on.

Tool calls travel over MCP, the protocol AI clients use to list and call tools. A bare MCP server stops at exposing tools. Workforce is the layer that resolves who is asking, decides whether their Group allows it, scans the payload, attaches the credential, and records the result.

The request path

  1. Resolve the employee. A tool call arrives with the token the client received when the employee signed in through your identity provider. A model request arrives with a Gateway API key. Either one resolves to a single employee, synced from your identity provider by SCIM, and to the Groups they belong to.
  2. Check what the Group grants. For a tool call, the Tool Packs assigned to the employee’s Groups decide whether that tool is in reach. A call outside the set fails, and the ask lands in Requests. For a model request, the Group’s model access decides which models are candidates.
  3. Scan the payload. Security Gateway evaluates your Standard Entity Rules, Custom Regex Rules, and AI Guardrails against the arguments before they leave Workforce. A match redacts the matched value, or blocks the call outright.
  4. Route and check spend. A model request resolves a routing policy, which picks the model and the vendor. The budget on the employee’s Group is enforced here, before any vendor is called, so a request that exceeds it costs nothing.
  5. Execute. A tool call goes out through the Connector with the employee’s stored credential, refreshing the OAuth token if it is near expiry. A model request goes to the vendor the policy chose, failing over to the next candidate on a throttle or an outage.
  6. Log. Tool calls land in Tool call logs, model requests in LLM calls, and every configuration change in the Audit trail. Redactions are recorded, and blocks surface as alerts.

Identity is resolved first, which is why deprovisioning someone in your identity provider ends both halves at once. Scanning and spend gates run before the outbound call, so nothing leaves and nothing is billed on a request that fails a rule.

The objects you configure

ObjectWhat it is
EmployeeOne person in your directory, synced by SCIM. Every credential, tool call, model request, and log line is attached to one, so the employee is the unit of isolation and of attribution
GroupA group from your identity provider, synced by SCIM. It carries tool access, model access, a dashboard role, and optionally a budget. An employee in two Groups gets the most permissive access across both
ConnectorA packaged integration with one third-party service, such as Salesforce, Slack, Jira, or Drive. Workforce ships hundreds of them. You enable them rather than build them
ToolOne action a Connector exposes, named <connector>__<tool> on the wire so two Connectors with overlapping concepts do not collide
Tool PackA named bundle of Connectors and specific tools, and the thing you assign to a Group. It answers “what is this team allowed to do”
SkillA procedure you publish so employee agents run your playbook instead of inventing one. See Skills
Routing policyThe rules that pick a model and a vendor for each model request. A policy is scoped to a Group or is the organization default, and the Group scope wins where both apply
ProjectGateway’s own unit for grouping model traffic. Each Group’s budget and routing policy are held on one, which is how a Group’s spend reports separately
BudgetA hard spend cap on a Group, for a window from daily to yearly. Exhausting it returns 402 before any vendor is called

Your organization owns the Groups, Connectors, Tool Packs, skills, and policies. Each employee holds the credentials they have authorized and belongs to any number of Groups. Everything on the request path above reads from those two facts.

Next

Connect your identity provider and map your first Group in Get started.