> ## Documentation Index
> Fetch the complete documentation index at: https://docs.originhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Invite Users and Assign Roles in the Origin Console

> Invite team members and assign one of Origin's eight built-in roles, from Tenant Admin down to No Data Access. Every role applies across the whole tenant.

Origin ships eight built-in roles covering the operating personas a security program runs. This page explains how access is granted, what each role can reach, and how to invite people into your tenant.

## How access is granted

Every user holds one or more **grants**. A grant pairs a person with a role:

```text theme={null}
grant  =  user · role
```

Every role applies across the whole tenant. Nothing about a role is implicit — if a capability isn't granted to a role, that role can't reach it.

<CardGroup cols={2}>
  <Card title="Roles stack" icon="layer-group">
    A person can hold more than one grant. Permissions **union** — the user gets everything any of their roles allow.
  </Card>

  <Card title="Sensitive content is separate" icon="lock">
    Reading metadata and reading actual prompt or payload *content* are different permissions. A role can see that activity happened without seeing what was said.
  </Card>
</CardGroup>

<Note>
  A user with no explicit grant defaults to a single **Viewer** grant.
</Note>

## The eight built-in roles

Five roles work with monitored data; three are operational or limited.

### Data-facing roles

| Role                   | Persona                         | What it can do                                                                                                                                        |
| ---------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tenant Admin**       | Tenant owner / IT manager       | Full access to everything in the tenant, including sensitive content and destructive operations. Treat it like root — grant sparingly.                |
| **SecOps**             | SOC analyst / security engineer | Reads telemetry and runs analytics, including row-level queries — but never sees raw event payloads or prompt/response text.                          |
| **Detection Engineer** | Detection content owner         | Everything SecOps can do, plus the raw event content and prompt text needed to write and tune detections. The only non-admin role that reads prompts. |
| **IT / Fleet Admin**   | Endpoint / fleet administrator  | Manages endpoints and provisioning, reads installers and directory data. No event content and no analytics access.                                    |
| **Viewer**             | Auditor / exec / read-only      | Reads counts, distributions, metadata, and tenant configuration across the tenant. Never sees sensitive content or raw rows.                          |

### Operational and limited roles

These three are defined by what they *can't* reach.

| Role                     | Persona                         | What it can do                                                                                                                                  |
| ------------------------ | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Vendor Support**       | External support engineer       | Fleet and operational health for troubleshooting a deployment. Never sees monitored content — events, AI sessions, directory PII, or analytics. |
| **Security Engineering** | Platform / integration engineer | Manages integrations (SIEM, OTEL) and platform configuration under segregation of duties. No monitored-data read, no user or role management.   |
| **No Data Access**       | Familiarization / training      | Signs in and navigates the interface only. Holds no permissions and sees no tenant or operational data.                                         |

<Note>
  For a row-by-row breakdown of what every role can reach — endpoints, event content, prompt text, analytics, directory data, signals, and administration — see [Access Control](/product/role-based-access-control).
</Note>

## The User Management view

Open **Settings → User Management** at [dashboard.originhq.com](https://dashboard.originhq.com/). The table lists every user in your tenant.

| Column         | Description                                   |
| -------------- | --------------------------------------------- |
| **Email**      | The user's sign-in address                    |
| **Name**       | Display name                                  |
| **Role**       | The role currently assigned                   |
| **Membership** | The user's organization membership identifier |

Use the search box to filter by email, name, or role, and **Columns** to change which columns are visible. Each row carries three actions: **Change role**, **Reset PW**, and **Remove**.

<Note>
  Only **Tenant Admin** can invite users, remove users, or change a user's role.
</Note>

## Inviting a user

<Steps>
  <Step title="Open User Management">
    Sign in at [dashboard.originhq.com](https://dashboard.originhq.com/), click **Settings** in the far-left rail, then select **User Management**.
  </Step>

  <Step title="Open the invite dialog">
    Click **Invite user** at the top right.
  </Step>

  <Step title="Enter the email and pick a role">
    Type the user's email address, then choose a role from the dropdown. It lists all eight built-in roles and defaults to **Viewer**.

    The dialog shows the selected role's description beneath the field, so you can confirm the reach before sending.
  </Step>

  <Step title="Send the invite">
    Click **Send invite**. The user receives a WorkOS invitation email and joins the organization once they accept.
  </Step>
</Steps>

<Note>
  The invite dialog collects an email and a role only.
</Note>

## Sensitive data is gated separately

Every analytics column is classed **Default** or **Sensitive**. Default covers metadata — timestamps, model names, identifiers, counts, status. Sensitive covers anything that exposes private content in bulk, and reading it needs a dedicated permission on top of the role's normal read.

| Sensitive surface                                           | Permission                         | Held by                           |
| ----------------------------------------------------------- | ---------------------------------- | --------------------------------- |
| Raw event payloads (command args, file content)             | `events.read.sensitive`            | Tenant Admin · Detection Engineer |
| AI prompt / response text                                   | `ai_sessions.read.sensitive`       | Tenant Admin · Detection Engineer |
| Endpoint metadata (installed software, processes, env vars) | `endpoint_metadata.read.sensitive` | Tenant Admin · Detection Engineer |
| Directory PII (name, email, phone, manager)                 | `directory_data.read.sensitive`    | Tenant Admin · Detection Engineer |

A query that **references** a sensitive column — in a result, a filter, a grouping, or a sort — without the matching permission is refused before it runs. A role that can't read a sensitive column never even sees it in the schema, so it can't build a query that touches one, and it can't probe values by guessing.

<Warning>
  AI prompt text is treated as the most sensitive surface in the product. Grant **Detection Engineer** to people who tune detections — not as a general power-user role.
</Warning>

## Choosing a role

<Tip>
  Start from least privilege and add capability only where a person's job requires it.
</Tip>

* **Start from least privilege.** Give analysts **SecOps**; add **Detection Engineer** only for the people who genuinely need to read prompt and payload content.
* **Viewer is read-only, not read-everything.** Auditors and execs see metadata, counts, and configuration — never sensitive content or raw rows.
* **IT / Fleet Admin runs the fleet, not investigations.** It manages endpoints and provisioning but has no event or analytics access.
* **Treat Tenant Admin like root.** It holds destructive operations and all sensitive content. Keep the holder count small.
* **Use Vendor Support for outside help** that needs deployment health but must never see monitored content, and **No Data Access** for training accounts that should see nothing.