# Users

Users is the Admin's lens on Agent delegation across the org: who has Agents set up, what those Agents access and how active each employee is. Each row drills into a detail page.

***

### 📖 Key concepts

* **employee**: A person in the organization, synced from your HRIS or IdP or invited manually.
* **Delegation**: An employee allowing one or more Agents to act on their behalf via the MCP Gateway.
* **Delegation scope**: The total footprint of one employee's Agent activity: Agent count, Connections accessed, tool calls.
* **Sync vs manual**: When HRIS/IdP sync is on, the sync is authoritative and Users are read-only here. When sync is off, Admins manage Users by hand.

:bulb: *Why this matters*: Employee attributes (department, title, location) already drive Policy conditions. The delegation map adds the second half: what each employee's Agents are doing.

***

### 📊 The Users table

* **Navigation**: Users.
* **What you see**: one row per employee.
  * **Name + email**, **Department**, **Role** and other HRIS attributes.
  * **Agents**: count of Agents acting on behalf of this employee.
  * **Connections**: icon stack of Connections accessed.
  * **Sessions (30d)**: Agent session count.
  * **Last active**.
* **Actions**: inviting, editing and removing Users requires HRIS/IdP sync to be off. When sync is on, your identity provider is the source of truth and these records are read-only here.
  * **Invite user**: creates a User record and sends the invite.
  * **Edit**: name, department, role, job title, team. These feed Policy conditions.
  * **Remove**: deletes the employee record.

***

### 🛠 User detail

**Navigation**: Users → click any row. The detail page opens on the Overview tab.

#### Overview

* **What you see**: identity and HRIS attributes (department, team, job title, tenure); an activity summary (sessions, Agent count, Connections count, last active); and a delegation scope summary, for example `This User has delegated to 3 Agents accessing 5 Connections with 284 tool calls in the last 30 days.`
* **Why it matters**: one line tells you whether this employee is a heavy delegator or a light user.

#### Connections

* **What you see**: every Connection this employee holds credentials for, with Connection status (Active / Error / Paused / Not Connected), the Agents that use it, sessions (30d) and last active.
* **Actions**:
  * **Add connection access**: create a User-Connection association manually.
  * **Revoke connection**: pull the credential. The employee keeps their underlying app access.
  * **Remove connection access**: delete the User-Connection record (house-cleaning).

#### Sessions

* **What you see**: every session this employee delegated, across all Agents and Connections. The same nested pattern used elsewhere: Level 1 sessions, Level 2 tool calls, and a side panel with payloads and the Policies that fired.
* **Why it matters**: the investigation surface for one employee's activity.

***

### 📋 Users at a glance

| Surface         | Where                     | What you see / can do                                                                                      | Why it matters                              |
| --------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| **Users table** | Users                     | One row per employee: Agents, Connections, sessions, last active. Invite, edit and remove (sync off only). | The delegation map across the org.          |
| **Overview**    | Users → row               | Identity, HRIS attributes and the delegation scope summary.                                                | Heavy delegator or light user, in one line. |
| **Connections** | Users → row → Connections | Per-Connection status and activity for this employee. Revoke or remove access.                             | Per-credential view for one employee.       |
| **Sessions**    | Users → row → Sessions    | Every delegated session, drillable to tool calls and the Policies that fired.                              | Investigate one employee's activity.        |

***

### 🔗 Related pages

* [All Agents](/docs/ai-agent-access/how-to-guides/agents/all-agents.md)
* [All Connections](/docs/ai-agent-access/how-to-guides/connections/all-connections.md)
* [Agent Activity](/docs/ai-agent-access/how-to-guides/agents/agent-activity.md)
* [Policies](/docs/ai-agent-access/how-to-guides/policies.md)
* [Org Settings](/docs/ai-agent-access/how-to-guides/org-settings.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.cakewalk.security/docs/ai-agent-access/how-to-guides/users.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.