# Origin Agent Installation: Supported Platforms and Methods
Source: https://docs.originhq.com/getting-started/agent-overview
The Origin agent is a background service for Windows and macOS that monitors AI traffic in real time. Learn supported OS versions and deployment methods.
The Origin agent supports the latest versions of Windows 10, Windows 11, Windows Server 2022+, and macOS 13 (Ventura) or later. The agent can be installed manually by an administrative user, or it may be deployed using standard MDM/management tools.
The agent runs as a service and includes the core agent and a watchdog service.
## Supported platforms
| Platform | Minimum version |
| - | - |
| Windows 10 | Latest builds |
| Windows 11 | Latest builds |
| Windows Server | 2022 and later |
| macOS | 13 (Ventura) or later |
## Next steps
Run the `.pkg` installer, register the agent, and confirm it is reporting in the Origin dashboard.
Deploy the MSI silently with a provisioning JWT, with options for enhanced logging.
Push the agent fleet-wide using Jamf, Intune, or Tanium.
Confirm the agent is healthy and capturing AI activity using tray diagnostics, service checks, and test prompts.
# AI Provider Support: Supported Tools and Capture Methods
Source: https://docs.originhq.com/getting-started/ai-providers
Which AI applications Origin captures, how each one is captured (OpenTelemetry, application hooks, or API integration), and where to set up the integrations.
Origin's supported applications are captured using three integration methods — **OpenTelemetry**, **application hooks**, and **API integration**.
In the tables below:
* The **Endpoint** column lists applications captured on the endpoint, via OpenTelemetry and application hooks. These need the Origin agent installed on the device, and nothing else.
* The **API** column lists applications captured through API integration. These are read from the provider's cloud, so they cover activity on devices that aren't running the agent — but each one needs a one-time setup in **Settings**.
## Application support
| Provider | Endpoint | API |
| - | - | - |
| **Anthropic** | Claude Code (CLI), Claude Code (Desktop), Claude Cowork | Browser (claude.ai), Claude Desktop Chat |
| **OpenAI** | Codex CLI, ChatGPT Desktop (Chat, Work, Codex) | ChatGPT, app/MCP calls, Codex sessions (Preview) |
| **Microsoft** | GitHub Copilot CLI | M365 Office Applications, M365 Copilot, copilot.microsoft.com |
| **Cursor** | Cursor Desktop | — |
## Set up the API integrations
Endpoint capture works as soon as the agent is installed. The API-based integrations each need to be connected once from the Origin dashboard.
Connect your Claude Enterprise account through Anthropic's Compliance API to pull `claude.ai` and Claude Desktop activity, including from endpoints that aren't running the agent.
Capture Copilot prompts and responses across Word, Excel, Outlook, Teams, and Copilot Chat by reading Microsoft's own cloud APIs. Requires the Entra ID directory integration.
**Preview.** Connect a ChatGPT workspace or API-Platform organization through OpenAI's Compliance API (Enterprise Compliance Logs Platform) to pull ChatGPT, app/MCP, and Codex activity, including from endpoints that aren't running the agent.
## AI tools not on this list
Because Origin captures at the application layer rather than by matching network traffic, support for an application depends on that application exposing telemetry Origin can collect — an OpenTelemetry exporter, or a surface an application-level hook can attach to. Coverage is added per application rather than configured per domain.
If your organization depends on an AI tool that isn't listed above, contact Origin support with the application name and how your teams use it.
# Origin Console Setup: Endpoints, Admin, and Your Account
Source: https://docs.originhq.com/getting-started/console-setup
Where tenant configuration lives in the Origin console, across the Endpoints tab, the Admin tab, and the account menu, plus the setup order for a new tenant.
Configuring a new Origin tenant means working across three places in the console: the **Endpoints** tab (connecting and configuring devices), the **Admin** tab (users, directory sync, and AI data sources), and your account menu (personal account settings and feedback). Sign in at [dashboard.originhq.com](https://dashboard.originhq.com/) to get started.
## Where configuration lives
The full inventory of every registered endpoint in the tenant, with search, filtering, and column management.
Mint a provisioning token, download an installer, and get the install command — the fastest path to connecting a new endpoint.
Fleet-wide agent settings pushed to every endpoint: tray icon visibility and the OTLP collector port.
Invite team members and assign one of the eight built-in roles.
Connect Microsoft Entra ID, Okta, or Google Workspace to sync users, groups, and devices.
Add the Anthropic Compliance API key and enable Microsoft 365 Copilot capture.
Your own access scope, password, and locally-cached browser data.
Report a bug or request a feature directly from the console.
## Console layout
The console's main navigation (the far-left rail) has six sections: **Dashboard**, **Explore**, **Library**, **Endpoints**, **AI Governance**, and **Admin**. Setup and configuration is split across two of these:
* **Endpoints** — everything about connecting and managing devices: the endpoint inventory (**Overview**), a guided quick-connect flow plus the full provisioning token and installer lists (**Connect**), and fleet-wide agent settings (**Configuration**).
* **Admin** — everything about tenant-level configuration: users and roles (**Access**), directory connections (**Identity**), and external AI activity connectors (**Data Sources**).
Your own account settings and the feedback form are not part of Admin — they live under your avatar in the bottom-left corner, since they apply to you personally rather than to the tenant. Click your avatar to open **My Account** or **Send Feedback**.
## Setup order
If you are configuring a new tenant, work through these in order:
Add users and assign roles under **Admin → Access**. See [User Management](/getting-started/user-management).
Set up **Admin → Identity** so users and AI activity are attributed to real people. See [Directory Integrations](/product/identity-integration).
Set the OTLP collector port and tray-icon visibility under **Endpoints → Configuration**, before agents are deployed. See [Endpoint Configuration](/getting-started/endpoint-configuration).
Add the Anthropic Compliance API key and enable Microsoft 365 Copilot capture under **Admin → Data Sources**. See [AI Provider Support](/getting-started/ai-providers).
Use **Endpoints → Connect** to mint a provisioning token, grab an installer, and run the install command. See [Provisioning Tokens](/getting-started/provisioning-tokens) and [Installers](/getting-started/installers).
Roll the agent out at scale via MDM, or point people at the manual installers. See [Agent Overview](/getting-started/agent-overview) and [MDM Overview](/getting-started/mdm-overview).
# Endpoint Configuration
Source: https://docs.originhq.com/getting-started/endpoint-configuration
Configure agent settings pushed to every endpoint in the tenant from Endpoints → Configuration: tray icon visibility and the OTLP collector port.
Agent settings pushed to every endpoint in the tenant, from **Endpoints → Configuration** in the console. Changes apply on the next agent heartbeat, so you never need to touch individual machines.
This page applies across the tenant's endpoint fleet, not only to this browser or account. For your own personal account settings, see [My Account](/getting-started/settings-view).
## Opening Endpoint Configuration
Sign in at [dashboard.originhq.com](https://dashboard.originhq.com/), click **Endpoints** in the far-left rail, then select **Configuration**.
## Fleet settings
| Setting | Default | Description |
| - | - | - |
| **Hide system tray icon** | Off | Suppresses the tray process and removes the auto-start entry. |
| **OTLP collector port** | 4318 | Loopback port the agent's AI-telemetry collector binds on each endpoint. Leave empty for the default. |
### OTLP collector port
Set this if your endpoints already run a corporate OTel collector — Datadog, Alloy, Dynatrace — on 4318.
The port applies the next time each endpoint's agent restarts. Changing an already-configured port can briefly pause capture on macOS endpoints until each agent reconnects.
If the chosen port is already in use on a host, that host won't capture AI telemetry until the conflict is cleared — coordinate the port with whoever owns those endpoints.
The card shows a **Last saved** timestamp, and **Discard** / **Save** buttons. Changes are not pushed until you save.
Additional fleet configuration is available with the **AI Visibility** feature. If your tenant doesn't have it, the options above are the full set exposed on this page.
## Related pages
View every registered endpoint, under **Endpoints → Overview**.
Mint the tokens agents use to register, under **Endpoints → Connect**.
# Download Origin Agent Installers
Source: https://docs.originhq.com/getting-started/installers
The Installers view lists every published Origin agent build for macOS and Windows, with format, version, size, and SHA256 checksum for verification.
The **Installers** view is where you download the Origin agent packages. Open it from **Endpoints → Connect**, then click **Installers** in the top-right of the panel — or [jump straight there](https://dashboard.originhq.com/?mode=endpoints\&adminView=installers).
![The Endpoints → Connect page, with the Installers and Tokens buttons in the top-right and the three-step mint token / download installer / run it flow below.]()
By default the view shows the **three latest builds** — one per platform and format. A counter above the table reads `3 latest` alongside the total number of published builds, and a **Show all versions** button expands the list to every build ever published. A search box filters on platform, architecture, format, version, or checksum.
## What the table shows
| Column | Description |
| - | - |
| **Platform** | macOS or Windows |
| **Architecture** | Universal for macOS; x64 for Windows |
| **Format** | PKG, MSI, or EXE |
| **Version** | Agent version |
| **Published** | Date and time the build was published |
| **Size** | Download size |
| **SHA256** | Digest for verifying the download |
Each row has its own **Download** button.
## Which package to use
| Platform | Format | Use it for |
| - | - | - |
| macOS | **PKG** | Every macOS install — manual and MDM alike. |
| Windows | **MSI** | MDM and software-distribution tooling (Intune, SCCM). Requires the Visual C++ redistributable already present. |
| Windows | **EXE** | Ad-hoc and one-off installs. Detects and installs the Visual C++ redistributable automatically. |
See [Windows Install](/getting-started/windows-installation) for the difference in more detail, and [macOS Install](/getting-started/macos-installation) for the `.pkg` walkthrough.
## Verifying a download
The **SHA256** column carries the digest of each package. Compare it against the file you downloaded before deploying it to a fleet:
```bash theme={null}
shasum -a 256 Origin.pkg
```
```powershell theme={null}
Get-FileHash -Algorithm SHA256 .\origin-installer-windows-x64.msi
```
**You also need a provisioning token.** Installers and Provisioning Tokens are two separate views, both reached from **Endpoints → Connect**. The package downloaded here cannot register an agent on its own — mint a token first (click **Tokens**, or use the **Mint a provisioning token** step on the Connect page). See [Provisioning Tokens](/getting-started/provisioning-tokens).
## Next steps
Run the `.pkg` installer and register the agent.
Deploy the MSI silently with a provisioning JWT.
Push the agent fleet-wide via Jamf, Intune, or Tanium.
Create the token each agent needs to register.
# Key Concepts in Origin: Terminology and Data Model
Source: https://docs.originhq.com/getting-started/key-concepts
Understand Origin's core terms — endpoints, agents, sessions, clusters, skills, and the analytics graph — before deploying or exploring the dashboard.
Before you deploy Origin or start exploring the console, it helps to understand the vocabulary Origin uses to describe your environment. The terms below map directly to objects you'll see in the dashboard, query through the chat interface, and reference in documentation. Each concept builds on the previous ones, so reading through in order gives you a solid mental model of how data flows from your endpoints to your console.
## Glossary
A managed macOS or Windows device where the Origin agent is installed and actively reporting. Each endpoint appears in the Registered Endpoints view with its own telemetry status, agent version, and activity history. One physical or virtual machine corresponds to one endpoint record in your tenant.
The lightweight background service installed on each endpoint that collects and reports AI inventory and event data. The agent collects AI event data using Otel, application hooks and other methods before streaming that data to your Origin tenant. It applies fleet-wide configuration settings pushed from the console on each heartbeat cycle.
An AI tool or API that the Origin agent observes — for example, Claude Desktop, Claude Cowork, ChatGPT Desktop, Codex, Gemini CLI, or GitHub Copilot. Origin ships with built-in detection rules for the most common AI agents and providers.
A single, discrete conversation or interaction between a user and an AI provider. A session groups together all of the prompts and responses that belong to one continuous exchange. Sessions are the primary unit you navigate when investigating activity on a specific endpoint.
An individual request sent by a user to an AI model, along with the model's response. Prompts are the lowest-level unit of AI activity that Origin captures. Each prompt is timestamped, attributed to a user and endpoint, and associated with the session it belongs to.
A semantically grouped set of AI prompts that Origin has automatically identified as belonging to the same topic or work pattern. Clusters are named automatically based on the content of the prompts they contain. They help you understand *what* AI is being used for across your fleet without reading every individual prompt.
A signed JSON Web Token that authorizes an Origin agent installation to register with your specific tenant. You generate provisioning tokens from **Endpoints → Connect** and supply them during agent installation — either interactively or silently via an MDM deployment script. Treat a provisioning token like a password: rotate it if it is compromised and do not commit it to source control.
Your organization's isolated Origin account. All endpoints, users, sessions, configuration settings, and telemetry data in your deployment belong to a single tenant. Users from outside your tenant cannot access your data, and your tenant's configuration does not affect any other organization.
Folders of instructions, scripts, and resources that an AI assistant loads dynamically to improve its performance on specialized tasks. Skills teach an AI how to complete specific workflows in a repeatable, consistent way — whether that's following company brand guidelines, executing a standard analysis routine, or automating a recurring task. Skills can be created by individual users, provisioned by an organization, or sourced from third-party providers.
Origin inventories all skills present on Origin-managed endpoints, giving administrators visibility into which skills are installed across the fleet, their versions, and how frequently they're being used. Administrators can also deploy approved skills to managed devices directly from the Origin console, ensuring teams use standardized, vetted capabilities.
The underlying data model that powers both the Origin dashboards and the natural-language chat interface. The analytics graph connects endpoints, users, sessions, prompts, and clusters into a unified, queryable structure. When you ask Origin a question in the chat interface, it queries the analytics graph to generate its answer.
## Quick-reference table
| Term | One-line definition |
| - | - |
| **Endpoint** | A managed device (macOS or Windows) with the Origin agent installed |
| **Origin Agent** | The lightweight service that collects AI event data via OTel and application hooks |
| **AI Agent / Provider** | An AI tool or API being observed (e.g. Claude, Copilot, ChatGPT) |
| **Session** | A single conversation or interaction with an AI provider |
| **Prompt** | An individual request-and-response pair sent to an AI model |
| **Activity Cluster** | A semantically grouped, auto-named set of related prompts |
| **Provisioning Token (JWT)** | The credential used to register an agent against your tenant |
| **Tenant** | Your organization's isolated Origin account |
| **Skills** | Uploadable behavioral units available to the Origin AI assistant |
| **Analytics Graph** | The data model powering dashboards and the chat interface |
When you're ready to see these concepts in action, start with the [Console Setup](/getting-started/console-setup) guide to configure your tenant, then move on to deploying the agent to your first endpoint.
# How to Install the Origin Agent on a macOS Endpoint
Source: https://docs.originhq.com/getting-started/macos-installation
Install the Origin agent on macOS in five minutes: run the .pkg, approve system extensions, and confirm your endpoint in the Origin dashboard.
This guide walks you through installing the Origin agent on a macOS endpoint, from running the installer to confirming the agent is reporting in. The whole flow takes about five minutes and requires:
* A macOS host you can sign in to as an admin.
* The Origin agent `.pkg` installer for your tenant.
* The **JWT provisioning token** from your Origin dashboard.
**Where to get the installer and token**
Both live in the Origin dashboard under **Endpoints → Connect**. Download the latest `.pkg` and copy the JWT to your clipboard before you start.
## Step 1 — Launch the installer
Double-click the `.pkg` you downloaded. macOS opens the standard Installer app.
Click **Continue**.
## Step 2 — Confirm the install location
The installer shows the disk it will install to (typically *Macintosh HD*) and the disk-space footprint (\~89 MB).
Click **Install**.
## Step 3 — Authenticate to install
macOS prompts for your admin password to allow the installer to write to system locations.
Enter your password and click **Install Software**.
## Step 4 — Paste the registration token
After the package extracts, the **Origin Agent Registration** dialog appears. Paste the JWT provisioning token you copied from the dashboard.
Click **Register**.
## Step 5 — Allow the installer to control System Events
The installer needs to drive **System Events** to finish wiring the agent into the OS so it launches and stays running at login.
Click **Allow**.
## Step 6 — Grant Full Disk Access
The agent prompts you to grant **Full Disk Access** so it can read application logs and detect AI tooling installed in user-scoped locations.
Click **OK**. macOS opens **System Settings → Privacy & Security → Full Disk Access**.
1. Click the **+** button at the bottom of the list.
2. Navigate to `/Applications` and select **Origin.app**.
3. Click **Open**, then toggle the row on.
The agent will start automatically as soon as the toggle flips on.
## Step 7 — Confirm background activity
macOS posts a notification confirming the agent is allowed to run in the background at login and startup.
You're done. The agent is now reporting in. Check the Origin dashboard — the host should appear in the **Endpoint Explorer** within a minute.
## Verify the install
Open the menu bar **Origin** icon — a green dot means the agent is healthy. You can also run the built-in health check from there.
If the host doesn't appear in the dashboard within a couple of minutes, see *Log Locations* below for the install and runtime logs.
For a full end-to-end verification workflow, see [Verifying Agent Installations](/getting-started/verifying-installation).
## Log Locations
| Log | Path |
| - | - |
| Install & Registration | `/Library/Origin/logs/origin-setup.log` |
| macOS Install Log | `/var/log/install.log` |
| Agent Runtime | `/Library/Origin/logs/origin-agent.log` |
## Menu Bar Icon
The macOS Origin install creates a menu bar icon. This provides visibility into the overall health of the agent, allows you to run a health diagnostic report, and provides quick access to agent logging.
# Deploy the Origin macOS Agent via Microsoft Intune
Source: https://docs.originhq.com/getting-started/macos-via-intune
Push the Origin macOS agent silently to managed endpoints using Microsoft Intune — one PPPC profile, a JWT staging script, and a macOS PKG app deployment.
A step-by-step walkthrough for silent deployment of the Origin macOS agent — configuration profile, JWT staging script, and end-to-end Microsoft Intune workflow.
## Step 01 — Prerequisites
Confirm the following before proceeding:
* **Microsoft Intune admin center access** — Intune Administrator or equivalent role with permission to create configuration profiles, upload apps, and assign deployments.
* **An Apple MDM Push Certificate** that is active in Intune (**Devices → Enrollment → Apple → Apple MDM push certificate**). Without this, no macOS device can be managed.
* **A valid Origin provisioning JWT** (install token) — obtain from the Origin console under **Endpoints → Connect**.
* **The Origin macOS installer** — download from the Origin console under **Endpoints → Connect**. Delivered as `Origin.pkg`.
* **The configuration profile and install scripts** bundled with this guide (see files inventory in Step 03).
* **Target macOS devices enrolled in Intune with User-Approved MDM (UAMDM)**. Devices enrolled via Company Portal or Apple Automated Device Enrollment satisfy this requirement.
* **An Entra ID security group** containing your target devices — used during assignment in Step 05.
* **A pilot device** dedicated to validating the deployment chain end-to-end before broader rollout. The first device that receives a PKG app deployment in any tenant is at higher risk of agent-startup timing issues — validate on this device before scoping the app more broadly.
**Where to find it**
Both the `.pkg` installer and the provisioning JWT live in the same place in the Origin console: **Endpoints → Connect**. Grab both before moving into Intune.
Download the configuration profile from [MDM Overview](/getting-started/mdm-overview): [**origin-privacy.mobileconfig**](/getting-started/mdm-overview#mdm-configuration-profile). The JWT staging script is provided in full in Step 05 below.
## Step 02 — Scope of Automation
One macOS permission stands between the installer and a fully registered agent. MDM pre-approves it — no user interaction is required.
| Permission | Pre-approved by Profile? | User Action |
| - | - | - |
| Full Disk Access | Yes | None |
Deploying the privacy configuration profile before the package installs ensures the agent can register silently without any user-facing permission dialogs.
## Step 03 — Files
The configuration profile is downloadable from the docs site. The JWT staging script is reproduced in full in Step 05 — copy it straight into Intune.
| File | Purpose |
| - | - |
| `origin-privacy.mobileconfig` | PPPC profile — grants Full Disk Access to the Origin agent. |
| `intune-stage-jwt-origin.sh` | Standalone shell script that stages the provisioning JWT to `/var/tmp/origin-provisioning-jwt`. Deployed via **Devices → Scripts and remediations** before the macOS app (PKG) deployment. Idempotent — safe to retry. |
### Identifiers
| Identifier | Value |
| - | - |
| Team ID | `D3C73MWD7Y` |
| Agent bundle ID | `com.origin.agent` |
## Step 04 — Deployment Order
The privacy configuration profile should land on the endpoint before the `.pkg` installs — otherwise the agent hits a Full Disk Access prompt on first run. Follow this order strictly:
1. **Privacy preferences (PPPC)** (`origin-privacy.mobileconfig`) — Grants Full Disk Access to the Origin agent based on Team ID `D3C73MWD7Y` and bundle ID `com.origin.agent`. Eliminates the TCC prompt that would otherwise appear on first run.
2. **JWT staging shell script** (`intune-stage-jwt-origin.sh`) — Stages the provisioning JWT to `/var/tmp/origin-provisioning-jwt` via a standalone shell script policy at **Devices → Scripts and remediations**. Must show **Succeeded** on a target device before that device is added to the macOS app (PKG) assignment. Idempotent — safe to re-run.
3. **The Origin .pkg (via macOS app deployment)** (`Origin.pkg`) — The installer itself. Deployed as a macOS app (PKG) with no pre-install script. The `.pkg` postinstall reads the JWT staged in step 2 and registers silently. See Step 05 for the full app setup.
## Step 05 — Intune Walkthrough
The following sequence assumes you have the `origin-privacy.mobileconfig` profile plus the `.pkg` and the JWT staging shell script staged locally. The whole flow happens inside the Microsoft Intune admin center at `intune.microsoft.com`.
### 01. Upload the configuration profile
The `origin-privacy.mobileconfig` file must be uploaded as a **Custom** configuration profile. Do not use Intune's built-in PPPC template — it reconstructs the XML and breaks the code requirement that makes PPPC allow-listing work.
**Where to upload**
Intune admin center → **Devices → By platform → macOS → Configuration → Create → New Policy**. Set Profile type to **Templates**, then choose **Custom**. This is the only profile type that ingests a raw `.mobileconfig` without rewriting it.
1. Intune admin center → **Devices → By platform → macOS → Configuration**.
2. Click **+ Create → New Policy**.
3. Set Profile type to **Templates**, select **Custom**, click **Create**.
4. **Basics**: Name the profile (e.g. `Origin — Privacy Preferences (PPPC)`) and click **Next**.
5. **Configuration settings**:
* Custom configuration profile name: a friendly name shown on the device (e.g. `Origin Privacy Preferences`).
* Deployment channel: **Device channel** — required. The user channel will not allow the PPPC payload to take effect.
* Configuration profile file: upload `origin-privacy.mobileconfig`.
6. Click **Next**.
7. **Assignments**: add your Entra ID device group under **Included groups**. Click **Next**.
8. **Review + create → Create**.
**Verify before proceeding**
Before moving to the package, confirm the Origin privacy profile is installed using either method:
**Admin center:** Devices → All devices → select your test Mac → **Device configuration**. The profile should show status **Succeeded**.
**On the Mac:** System Settings → General → Device Management, or run:
```bash theme={null}
sudo profiles show -all | grep -i "origin"
```
This should return the Origin privacy profile. Do not proceed until it is confirmed installed on the target device.
### 02. Deploy the JWT staging shell script
This script stages the provisioning JWT to `/var/tmp/origin-provisioning-jwt` so the Origin `.pkg` postinstall can read it silently when the package installs. It is deployed as its own shell script policy — not as a pre-install script attached to the macOS PKG app.
1. Intune admin center → **Devices → Scripts and remediations → Platform scripts tab → + Add → macOS**.
2. **Basics:** Name `Origin — Stage Provisioning JWT`. Click **Next**.
3. **Script settings:** paste the script below, replacing the empty `JWT=""` value with your provisioning token from **Endpoints → Connect** in the Origin console. Settings:
* Run script as signed-in user: **No** (run as root).
* Hide script notifications on devices: **Yes**.
* Script frequency: **Not configured** (run once).
* Max number of times to retry if script fails: **3**.
4. **Assignments:** add your Entra ID device group. Click **Next**.
5. **Review + add → Add**.
6. Force a sync from Company Portal on your pilot device. Wait for status to show **Succeeded**.
```bash theme={null}
#!/bin/bash
# Origin Agent -- Intune JWT Staging Script
# Stages the provisioning JWT to /var/tmp/origin-provisioning-jwt.
# Deploy via: Devices > Scripts and remediations > macOS
LOG="/Library/Logs/Origin/intune-stage-jwt.log"
JWT_FILE="/var/tmp/origin-provisioning-jwt"
####################################################################
# EDIT THIS: paste your provisioning JWT between the quotes
JWT=""
####################################################################
# All output goes to the log file -- never to stdout.
mkdir -p "$(dirname "$LOG")"
exec >>"$LOG" 2>&1
echo "--- $(date -u +%Y-%m-%dT%H:%M:%SZ) starting ---"
# Idempotency: if Origin is already running, no-op success.
if pgrep -x origin >/dev/null 2>&1; then
echo "Origin agent already running; skipping JWT staging."
exit 0
fi
# Idempotency: if JWT already staged with content, no-op success.
if [[ -s "$JWT_FILE" ]]; then
echo "JWT already staged; skipping."
exit 0
fi
# Validate JWT is configured.
if [[ -z "$JWT" ]]; then
echo "ERROR: JWT not configured. Edit the script body."
exit 1
fi
# Stage the JWT atomically.
umask 077
printf '%s' "$JWT" > "$JWT_FILE.tmp"
chmod 600 "$JWT_FILE.tmp"
mv -f "$JWT_FILE.tmp" "$JWT_FILE"
echo "JWT staged successfully ($(wc -c < "$JWT_FILE") bytes)."
exit 0
```
On the device, verify the JWT was actually staged: `sudo ls -la /var/tmp/origin-provisioning-jwt` should show a `0600`-mode file owned by `root:wheel` with content. Until this is confirmed, do not proceed to Substep 04.
**Why the token lives in the script body**
Intune doesn't expose script parameters for macOS shell scripts the way it does for Windows Win32 apps — the script body is the only place to put the JWT. Any Intune admin with read permission on this script policy can see it. Scope admin permissions accordingly. For organizations where this exposure is unacceptable, see the tenant-signed PKG path that eliminates JWT staging entirely.
### 03. Add the Origin package as a macOS PKG app
The Origin `.pkg` is deployed using Intune's **macOS app (PKG)** deployment type. The PKG app has **no pre-install or post-install script** — JWT staging was handled in Substep 02. The `.pkg` postinstall reads the staged JWT directly when the package installs.
**Intune Management Extension prerequisite**
The macOS app (PKG) deployment type requires the Microsoft Intune Management Extension (version 2309.007 or greater) on the endpoint. The Intune Management Extension installs automatically on the first script- or PKG-type assignment, so the JWT staging script in Substep 02 should already have triggered it. If that script never reported **Succeeded**, the Intune Management Extension may not be healthy on the device — diagnose before continuing (see Step 07).
### 04. Configure requirements, detection, and assignment
1. Intune admin center → **Apps → All apps → + Create**.
2. Under **Other**, select **macOS app (PKG)**, then click **Select**.
3. **App information → Select app package file:** upload `Origin.pkg`. Intune reads bundle ID and version from the package metadata.
4. Confirm the auto-populated values, fill in **Publisher** (e.g. Prelude Research) and any optional fields. Click **Next**.
5. **Program:** leave both **Pre-install script** and **Post-install script** blank. This is critical — adding a pre-install script reintroduces the failure modes documented in Step 07.
6. Set **Ignore app version** to **No** so Intune respects the version in the package metadata for upgrade decisions.
7. Click **Next** to continue to **Requirements**.
| Setting | Value |
| - | - |
| Minimum operating system | macOS 13.0 or later (matches Origin's supported OS floor) |
**Detection rules**
| Field | Value |
| - | - |
| Rules format | Use included app rules (default) — Intune detects via the bundle IDs included in the `.pkg` |
| Action | Leave defaults — Intune populates from the package |
**Assignments**
| Field | Value |
| - | - |
| Required | Add the same Entra ID device group used for the configuration profile |
| Available for enrolled devices | Leave empty (this would let users self-install via Company Portal — not what we want for a silent rollout) |
| Uninstall | Not supported for macOS PKG apps deployed via Intune Management Extension |
Review the values and click **Create**.
**Required ordering before assigning the PKG app**
Intune has no built-in dependency mechanism between scripts and apps. Order is enforced by gating which devices receive each assignment:
1. The privacy configuration profile (Substep 01) should be assigned to your full pilot/rollout group from the start.
2. The JWT staging script (Substep 02) should also be assigned broadly — it's idempotent, so over-assigning is safe.
3. The macOS PKG app (this substep) should be assigned to a narrower sub-group that you populate only after a device shows **Succeeded** on both the privacy profile and the JWT staging script. For pilot validation, populate the sub-group manually one device at a time. For broader rollout, automate population via a dynamic group whose membership rule keys off a custom attribute the JWT script writes on success.
### 05. Trigger the install
Once a device is in scope for the macOS PKG app (with the upstream privacy profile and JWT staging script already **Succeeded**), the install runs automatically on the next device check-in. To force it for testing:
* **From the Mac:** open Company Portal → Devices → select the device → ⋯ → **Check status**. This forces an immediate sync.
* **From the admin center:** Devices → All devices → select the target device → **Sync**.
* **From Terminal on the Mac** (forces a profile check-in only — does not directly trigger app install): `sudo profiles renew -type enrollment`
**End-to-end flow:** the privacy profile applies → the JWT staging script writes `/var/tmp/origin-provisioning-jwt` (installing the Intune Management Extension on its first run) → Intune Management Extension installs the `.pkg` → the postinstall reads the staged JWT, registers silently, and deletes the file. No user interaction is required at any step.
## Step 06 — Verification
Run these on a target endpoint after the install completes. Each command confirms a different stage of the install pipeline is healthy.
**Profile installed**
```bash theme={null}
sudo profiles show -all | grep -i "origin"
```
Should return the Origin privacy profile.
**Agent process running**
```bash theme={null}
pgrep -x origin
```
Returns a PID when the agent is running.
**Review agent log**
```bash theme={null}
cat /Library/Origin/logs/agent.log.$(date -u +%Y-%m-%d)
```
Prints today's agent log. Useful for confirming the agent has started cleanly, registration succeeded, and there are no errors after install.
**JWT staging script log**
```bash theme={null}
sudo cat /Library/Logs/Origin/intune-stage-jwt.log
```
Should show a successful run with `JWT staged successfully (NNN bytes).` or one of the idempotency no-op messages if the JWT was already staged or Origin was already running.
**Intune Management Extension log**
```bash theme={null}
sudo tail -n 100 /Library/Logs/Microsoft/Intune/IntuneMDMDaemon*.log
```
Confirms the package installed cleanly. Look for `App install succeeded` for the Origin policy ID. If you see `Cached app policy result matches` repeatedly without resolution, see Step 07.
### Origin menu bar icon
Once the agent is running, the Origin menu bar icon appears in the macOS menu bar. Click it to confirm the agent is active and to access two operator-friendly checks without dropping to Terminal:
* **Generate diagnostic report** — bundles agent state, recent logs, and registration status into a single file you can hand to Origin support.
* **View logs** — opens the local log directory directly, equivalent to the `cat` command above without needing the date.
**Origin console verification**
In the Origin console, click **Computers** in the left-hand navigation, then search for the target hostname. A successfully registered endpoint will appear in the list with a recent snapshot time and its detected AI agents populated.
**Intune admin center verification**
Devices → All devices → select the target Mac → **Managed Apps**. The Origin app should show install status **Installed**. Under **Device configuration**, the Origin privacy profile should show **Succeeded**.
## Step 07 — Troubleshooting
### Profile shows "Error" or "Conflict" in Intune
Check the per-device status in **Devices → All devices → \[device] → Device configuration → \[profile name] → Per-setting status**. The most common causes:
* **Profile uploaded with the wrong template type** — if you used Intune's built-in PPPC template instead of Templates → Custom, the XML was rebuilt and the code requirement no longer matches Origin's signature. Delete the profile and recreate it as a Custom profile uploading the raw `.mobileconfig`.
* **User channel selected instead of Device channel** — the PPPC payload is device-scoped and silently no-ops when delivered through the user channel. Recreate the profile with Deployment channel: **Device channel**.
* **Profile stuck in "Pending"** — force a sync from Company Portal on the device, or use **Sync** in the admin center.
* Verify the profile actually installed: `sudo profiles show -all | grep -i "origin"`.
### Full Disk Access not granted despite profile
* The PPPC profile's code requirement matches Developer ID signed builds with Team ID `D3C73MWD7Y`. Ad-hoc signed or internal development builds won't match and FDA will not pre-grant.
* Confirm the profile was uploaded as a Custom template (see above) — the built-in PPPC template will silently strip the code requirement.
### JWT staging script reports "Failed" but the JWT file exists
Diagnostic and fix for the case where the script ran but Intune reports failure:
* Verify the file actually exists with content: `sudo ls -la /var/tmp/origin-provisioning-jwt`. A `0600`-mode file owned by `root:wheel` with non-zero size means the script succeeded — Intune is misreporting.
* Check the script's own log: `sudo cat /Library/Logs/Origin/intune-stage-jwt.log`. If the log shows `JWT staged successfully` and `exit 0`, the script worked.
* **Recovery:** if the JWT is staged correctly, simply assign the macOS PKG app to the device — the postinstall will consume the JWT regardless of what Intune thinks of the script's status.
* If you need Intune to actually report success, toggle the script's group assignment off, wait 5 minutes, then re-assign. This forces Intune to re-evaluate from a fresh state. The script's idempotency check ("JWT already staged; skipping") returns 0 cleanly.
### PKG app reports "Pre-install script did not complete successfully (0X87D3014A)"
This means the macOS PKG app was configured with a pre-install script — which this deployment guide explicitly avoids. Open the app in **Apps → All apps → Origin app → Properties → Edit** and confirm both **Pre-install script** and **Post-install script** fields are blank. If they aren't, blank them, save, and re-sync.
### Cached failure persists across multiple sync attempts
Intune's macOS app retry logic has a documented weakness: when the `IntuneMDMDaemon`'s cached policy result matches a prior failure (visible as `Cached app policy result matches the current policy result` in `IntuneMDMDaemon*.log`), it stops retrying meaningfully. Recovery options in order of preference:
* **Toggle the assignment.** Apps → All apps → Origin → Properties → Assignments → remove the group → Save. Wait 5 minutes, force a sync from Company Portal, then re-add the assignment. Intune treats this as a brand-new policy and clears the cached result.
* **Retire and re-enroll.** If the assignment toggle doesn't break the cache, retire the device from the admin center, manually clean `/Library/Intune/` and `/Library/Logs/Microsoft/Intune/`, delete the device record from Intune, then re-enroll fresh via Company Portal. This is the only fully clean reset for a poisoned policy state.
* **Wait it out (not recommended).** Intune may eventually break the cache on its own, but timing is unpredictable.
### JWT staging script fails on first deployment
A failure on the very first script assignment usually indicates the Intune Management Extension itself isn't healthy on this device yet. Check `ls /Library/Intune/` — if empty or missing the agent app bundle, force a sync and wait 5–10 minutes for the agent to install, then let the idempotent script retry.
### App stays in "Pending" forever in Company Portal
* Confirm the device's primary user has an Intune license assigned in M365 Admin Center. Without the license, agent installation requests get silently dropped.
* Check that the device hasn't been added to a conflicting assignment that excludes it from the script policy.
* This is a known Intune cosmetic bug — Company Portal can show **Pending** even after the app has successfully installed. Verify with `pgrep -x origin` on the endpoint and the install status in the admin center, both of which are authoritative.
* If the install really hasn't started, confirm the device received the Intune Management Extension: `ls /Library/Intune/`. If empty, force a sync and wait — the agent installs on first PKG app or shell script assignment.
# Silent Fleet Deployment of the Origin Agent via Jamf Pro
Source: https://docs.originhq.com/getting-started/macos-via-jamf
Silently deploy the Origin macOS agent fleet-wide using Jamf Pro — one PPPC profile, a JWT staging script, and a zero-touch install policy.
A step-by-step walkthrough for silent deployment of the Origin macOS agent — configuration profile, install script, and end-to-end Jamf Pro workflow.
## Step 01 — Prerequisites
Confirm the following before proceeding:
* **Jamf Pro admin access** (scope permitting profile creation, package upload, policies, and scripts).
* **A valid Origin provisioning JWT** (install token) — obtain from the Origin console under **Endpoints → Connect**.
* **The Origin macOS installer** — download from the Origin console under **Endpoints → Connect**. Delivered as `Origin.pkg`.
* **The configuration profile and install script** bundled with this guide (see files inventory in Step 03).
* **Target macOS devices enrolled in Jamf Pro** with User-Approved MDM (UAMDM).
**Where to find it**
Both the `.pkg` installer and the provisioning JWT live in the same place in the Origin console: **Endpoints → Connect**. Grab both before moving into Jamf.
Download the configuration profile from [MDM Overview](/getting-started/mdm-overview): [**origin-privacy.mobileconfig**](/getting-started/mdm-overview#mdm-configuration-profile). The install script is provided in full in Step 05 below.
## Step 02 — Scope of Automation
One macOS permission stands between the installer and a fully registered agent. MDM pre-approves it — no user interaction is required.
| Permission | Pre-approved by Profile? | User Action |
| - | - | - |
| Full Disk Access | Yes | None |
Deploying the privacy configuration profile before the package installs ensures the agent can register silently without any user-facing permission dialogs.
## Step 03 — Files
The configuration profile is downloadable from the docs site. The install script is reproduced in full in Step 05 — copy it straight into Jamf.
| File | Purpose |
| - | - |
| `origin-privacy.mobileconfig` | PPPC profile — grants Full Disk Access to the Origin agent. |
| `jamf-install-origin.sh` | Pre-install shell script that stages the provisioning JWT for the `.pkg` postinstall. |
### Identifiers
| Identifier | Value |
| - | - |
| Team ID | `D3C73MWD7Y` |
| Agent bundle ID | `com.origin.agent` |
## Step 04 — Deployment Order
The privacy configuration profile should land on the endpoint before the `.pkg` installs — otherwise the agent hits a Full Disk Access prompt on first run. Follow this order:
1. **Privacy preferences (PPPC)** (`origin-privacy.mobileconfig`) — Grants Full Disk Access to the Origin agent based on Team ID `D3C73MWD7Y` and bundle ID `com.origin.agent`. Eliminates the TCC prompt that would otherwise appear on first run.
2. **The Origin .pkg (via policy)** (`Origin.pkg`) — The installer itself. Deployed via a Jamf policy with the install script running before the package to stage the provisioning JWT. See Step 05 for the full policy setup.
## Step 05 — Jamf Pro Walkthrough
The following sequence assumes you have the `origin-privacy.mobileconfig` profile plus the `.pkg` and install script staged locally.
### 01. Upload the configuration profile
The `origin-privacy.mobileconfig` file must be uploaded as a **raw custom profile**. Do not use Jamf's built-in PPPC payload editor — it rewrites the XML and breaks the code requirement.
**Upload location**
The **Upload** button is on the Configuration Profiles list page (**Computers → Configuration Profiles**), not inside the New Profile editor. Navigate to the list first, then click **Upload** to import a raw `.mobileconfig` file.
1. Jamf Pro → **Computers → Configuration Profiles**.
2. Click **Upload** on the list page.
3. Upload `origin-privacy.mobileconfig`.
4. Under the **Scope** tab, add your target devices or Smart Group.
5. Click **Save**.
**Verify before proceeding**
Before moving to package installation, confirm the Origin privacy profile is installed using either method:
**UI:** On the Mac, go to **System Settings → Privacy & Security → Profiles** (or search "Device Management"). The **Privacy Preferences** profile should appear in the managed profiles list.
**Terminal:**
```bash theme={null}
sudo profiles show -all | grep -i "origin"
```
This should return the Origin privacy profile. Do not proceed until it is confirmed.
### 02. Upload the Origin package
1. Jamf Pro → **Settings → Computer Management → Packages → Upload Package**.
2. Upload `Origin.pkg`.
3. Leave defaults (Category, Priority, Fill User Template, etc.) unless you have site-specific conventions.
4. Click **Save**.
### 03. Create the install script
The script stages the provisioning JWT to `/var/tmp/origin-provisioning-jwt` so the `.pkg` postinstall can read it silently. The file is deleted after use.
1. Jamf Pro → **Settings → Scripts → New**.
2. Name the script `Origin Installer`.
3. On the **Script** tab, paste the contents below, replacing the empty `JWT=""` value with your provisioning token from **Endpoints → Connect**.
4. Click **Save**.
```bash theme={null}
#!/bin/bash
# Origin Agent -- Jamf Silent Install Script
# Stages the JWT for the .pkg postinstall to read.
# The postinstall deletes the file after use.
set -euo pipefail
####################################################################
# EDIT THIS: paste your provisioning JWT between the quotes
JWT=""
####################################################################
if [[ -z "$JWT" ]]; then
echo "Error: JWT not configured. Edit the script and set the JWT variable."
exit 1
fi
JWT_FILE="/var/tmp/origin-provisioning-jwt"
install -m 600 /dev/null "$JWT_FILE"
echo "$JWT" > "$JWT_FILE"
echo "JWT staged for Origin installer."
```
**Why the token lives in the script body**
Jamf script parameters are capped at 255 characters, which is too short for a provisioning JWT. The token goes directly into the script body. Any Jamf admin with script-view permissions will be able to read it — scope admin permissions accordingly.
### 04. Create the install policy
1. Jamf Pro → **Computers → Policies → New**.
**General Tab**
| Field | Value |
| - | - |
| Display Name | Install Origin Agent |
| Trigger | Custom event: `install-origin` and **Enrollment Complete** |
| Execution Frequency | Once per computer |
**Packages Tab**
| Field | Value |
| - | - |
| Package | `Origin.pkg` |
| Action | Install |
**Scripts Tab**
| Field | Value |
| - | - |
| Script | Origin Installer |
| Priority | **Before** |
**Scope Tab**
| Field | Value |
| - | - |
| Target | Add the same target devices or Smart Group used for the configuration profile. Click **Save**. |
**Script priority must be Before**
If the script runs **After** the package, the JWT file won't exist when the postinstall needs it and the installer will fall back to the GUI prompt. Double-check the priority before saving.
### 05. Trigger the policy
On a target device, run the custom trigger from Terminal:
```bash theme={null}
sudo jamf policy -event install-origin
```
**Authentication note**
Running `sudo jamf policy -event install-origin` manually will prompt for interactive password authentication on the endpoint. If you prefer the install to run without any user interaction, simply wait for the device to check in naturally (on enrollment complete or the next recurring check-in) rather than forcing it with the manual command.
The script stages the JWT → Jamf installs the `.pkg` → the postinstall reads the staged JWT and registers silently → the JWT file is deleted. The MDM profile handles the Full Disk Access grant with no user interaction required.
## Step 06 — Verification
Run these on a target endpoint after the policy completes. Each command confirms a different stage of the install pipeline is healthy.
**Profile installed**
```bash theme={null}
sudo profiles show -all | grep -i "origin"
```
Should return the Origin privacy profile.
**Agent process running**
```bash theme={null}
pgrep -x origin
```
Returns a PID when the agent is running.
**Agent log tail**
```bash theme={null}
cat /Library/Origin/logs/agent.log.$(date -u +%Y-%m-%d)
```
Prints today's agent log. Useful for confirming the agent has started cleanly, registration succeeded, and there are no errors after install.
### Origin menu bar icon
Once the agent is running, the Origin menu bar icon appears in the macOS menu bar. Click it to confirm the agent is active and to access two operator-friendly checks without dropping to Terminal:
* **Generate diagnostic report** — bundles agent state, recent logs, and registration status into a single file you can hand to Origin support.
* **View logs** — opens the local log directory directly, equivalent to the `cat` command above without needing the date.
**Origin console verification**
In the Origin console, click **Computers** in the left-hand navigation, then search for the target hostname. A successfully registered endpoint will appear in the list with a recent snapshot time and its detected AI agents populated.
## Step 07 — Troubleshooting
### Profile shows "Failed" in Jamf
Check the error in the device's Management History. The two most common causes:
* **Code requirement no longer matches** — the profile was recreated in Jamf's payload editor, which rewrites the XML. Re-download [origin-privacy.mobileconfig](/getting-started/mdm-overview#mdm-configuration-profile) and upload it as a raw profile instead.
* **Profile stuck pending** — run `sudo jamf policy` on the device to force a check-in.
### Full Disk Access not granted despite profile
* Verify the profile actually installed:
```bash theme={null}
sudo profiles show -all | grep -i "origin"
```
* The PPPC profile's code requirement matches Developer ID signed builds with Team ID `D3C73MWD7Y`. Ad-hoc signed or internal development builds won't match and FDA will not pre-grant.
### JWT prompt still appears on install
* Verify the script ran successfully — check the policy logs in Jamf Pro.
* Confirm script priority is **Before**, not **After**.
* On the endpoint, confirm the file existed before the `.pkg` ran: `/var/tmp/origin-provisioning-jwt`.
## Step 08 — Alternative Deployment Paths
### Kandji
1. **Library → Add New → Custom Profile** for the `.mobileconfig`.
2. Assign to device blueprints.
3. Add the `.pkg` as a **Custom App**.
4. Use a pre-install script to stage the JWT (same pattern as the Jamf script above).
### Headless CLI install
For scripted deployments outside of any MDM — useful for lab environments, golden-image prep, or emergency reinstalls:
```bash theme={null}
echo "eyJ..." > /var/tmp/origin-provisioning-jwt
chmod 600 /var/tmp/origin-provisioning-jwt
installer -pkg Origin.pkg -target /
```
The postinstall reads the JWT from the staged file and skips the GUI prompt. The file is deleted after use.
Without the privacy profile, the end user will see the Full Disk Access prompt on first run — this path is best reserved for managed endpoints that already have the profile from an earlier MDM state, or lab machines where the prompt is acceptable.
# Deploy the Origin macOS Agent Silently via Tanium MDM
Source: https://docs.originhq.com/getting-started/macos-via-tanium
Use Tanium Device Management and Tanium Deploy to push the Origin macOS agent fleet-wide with fully automated, zero-touch installation.
A step-by-step walkthrough for silent deployment of the Origin macOS agent — configuration profile, install script, and end-to-end Tanium deployment flow.
## Overview
Deploying the Origin agent on macOS requires two Tanium products working in sequence:
* **Tanium Device Management** pushes the MDM configuration profile that pre-approves the system permission the agent needs. Without this profile, the agent will hit an interactive Full Disk Access dialog on first run and silent install will fail.
* **Tanium Deploy** stages the provisioning JWT and executes the installer, but only on endpoints where the profile has successfully installed.
The two products are independent — Device Management uses Apple's MDM/APNs channel, and Deploy uses the Tanium Client. Both must be in place on the endpoint before the agent install runs.
## Prerequisites
Before starting, confirm the following:
* Tanium Cloud admin access with permissions to configure Device Management (`Shared Services → Device Management`) and Deploy (`Modules → Deploy`)
* A Tanium license that includes **Tanium Enforce** (required by Device Management)
* An Apple Push Notification Service (APNs) certificate configured in Device Management — `Shared Services → Device Management → Settings → Push Certificate`
* Target Macs enrolled in Tanium Device Management (see Step 1)
* A valid Origin **provisioning JWT** — obtain from the Origin console under `Endpoints → Connect`
* The Origin **macOS installer** (`Origin.pkg`) — download from the Origin console under `Endpoints → Connect`
* The `origin-privacy.mobileconfig` configuration profile, downloadable below
**Configuration profile download:** [**origin-privacy.mobileconfig**](/getting-started/mdm-overview#mdm-configuration-profile)
## Files
| File | Purpose |
| - | - |
| `origin-privacy.mobileconfig` | PPPC profile — grants Full Disk Access to the Origin agent (Team ID `D3C73MWD7Y`, bundle ID `com.origin.agent`). |
| `Origin.pkg` | The macOS agent installer. |
| `jwt.txt` | A plain text file containing your provisioning JWT. Created by you — see Step 4. |
### Identifiers
| | |
| - | - |
| Team ID | `D3C73MWD7Y` |
| Agent bundle ID | `com.origin.agent` |
| App bundle | `/Applications/Origin.app` |
| CFBundleName | `Origin` |
| Current version | `1.1.0` |
| Minimum macOS | 13.0 (Ventura) |
## Deployment Order
The privacy configuration profile must reach **Installed** status on the endpoint before the Deploy package runs. The Deploy deployment is gated on this via a computer group (Step 5) — it will not run on a Mac until the profile is confirmed installed.
| Order | What | How |
| - | - | - |
| 1 | Privacy (PPPC) profile | Device Management custom setting |
| 2 | `Origin.pkg` via JWT staging | Tanium Deploy package |
## Step 1 — Enroll Macs in Device Management
Macs must be enrolled in Tanium Device Management before profiles can be pushed. Device Management enrollment also automatically installs the Tanium Client, which Deploy requires.
### Automated enrollment (recommended)
If your Macs are purchased through Apple Business Manager (ABM) or Apple School Manager (ASM), configure automated device enrollment so Macs enroll into Tanium Device Management at setup time with no user interaction required.
1. Go to `Shared Services → Device Management → Settings (GEAR icon, not the side menu) → Automated Enrollment`
2. Follow the prompts to link your ABM/ASM token and configure the enrollment experience
### Manual enrollment (testing / pilot)
For individual Macs not in ABM, download and install the enrollment profile manually:
1. Go to `Shared Services → Device Management → Settings (GEAR icon, not the side menu) → Device Enrollment`
2. In the **Manual Enrollment** section, click **Download** and select the macOS enrollment file
3. Copy the profile to the target Mac and install it
4. On the Mac, open the profile in System Settings and confirm installation
Once enrolled, the Tanium Client installs automatically. Verify enrollment by checking that the Mac appears in `Shared Services → Device Management` with a recent check-in time.
Alternatively, you can ask the question:
```text theme={null}
Get Computer Name and Device Management - Last Check-In Time and Device Management - Device ID from all entities with ( Is Mac equals true and Device Management - Device ID matches "^[\da-f]{8}-.*$" )
```
## Step 2 — Prepare and Upload the Configuration Profile
The privacy profile is uploaded as a Custom Setting in Tanium Device Management. Device Management pushes it via the MDM/APNs channel — no Tanium Enforce payload editors are used.
**Do not recreate this profile using Tanium Enforce's built-in payload editors.** The editors rewrite the XML and could break the code requirement in the PPPC profile. Upload the raw `.mobileconfig` file only.
### Upload the profile
1. Go to `Shared Services → Device Management → Settings`
2. In the **Custom Setting** section, click **+**
3. Name the setting `Origin - Privacy` — **use this exact name**. The computer group created in Step 5 matches against it in sensor output.
4. In **Choose a platform**, select **macOS**
5. In **Upload your profile**, drag and drop `origin-privacy.mobileconfig`
6. Click **Open**, then **Save**
| File | Setting name |
| - | - |
| `origin-privacy.mobileconfig` | `Origin - Privacy` |
## Step 3 — Create the Collection
A Device Management collection targets the setting to the appropriate devices.
1. Go to `Shared Services → Device Management → Collections`
2. Click **Add Collection**
3. Name the collection `Origin Agent - Profiles`
4. Click **Add** for the `Origin - Privacy` setting and click **Next**
5. Skip the Applications step and click **Next**
6. Configure targeting — select the computer group containing your target Macs
7. Click **Preview Targeted Endpoints** to verify scope, then **Save**
Allow a few minutes for the profile to push via MDM. Monitor progress on the collection's **Overview** tab — the setting should reach **Installed** before proceeding to Step 5.
## Step 4 — Verify the Profile on the Endpoint
Before building the Deploy package, confirm the profile is installed correctly on a test endpoint.
**Privacy profile installed:**
```shell theme={null}
sudo profiles show -all | grep -i "origin"
```
Should return the Origin privacy profile.
**In Tanium Interact**, confirm the sensor output looks correct — run this question against your test Mac:
```text theme={null}
Get Device Management - Settings Installation Status from all machines with Computer Name equals
```
You should see output like:
```text theme={null}
Origin - Privacy | Installed | Installation successful |
```
## Step 5 — Create the Computer Group
The Deploy deployment is scoped to this computer group. A Mac joins the group only when the Origin privacy profile is confirmed installed — this is the gate that prevents the Deploy package from running on unprepared endpoints.
1. Go to **Administration → Computer Groups**
2. Click **New Computer Group**
3. Name it `Origin Profiles Installed`
4. Set the filter expression to:
```text theme={null}
( Is Mac equals true
and Device Management - Settings Installation Status matches "^Origin - Privacy\s*\|\s*Installed.*$"
)
```
5. Click **Preview** to confirm your test Mac appears in the group
6. Click **Save**
**How the regex works:** The condition matches a row in the sensor output that begins with the profile name `Origin - Privacy`, followed by a pipe delimiter (with optional whitespace), followed by `Installed`. This ensures both the profile name and its status are confirmed together — a condition like `contains "Installed"` alone would match any profile that happens to be installed, not the specific one named.
## Step 6 — Create the Deploy Package
A single Deploy software package with three sequential commands handles JWT staging, installation, and cleanup.
### Package details
1. Go to `Modules → Deploy → Software → Software Packages`
2. Click **Create Package**
3. Fill in the package details:
| Field | Value |
| - | - |
| Name | `Origin Agent - Install (macOS)` |
| Vendor | `Prelude Research` |
| Version | `1.0.16` |
| Platform | `macOS` |
### Package files
In the **Package Files** section, upload both files:
* `Origin.pkg`
* `jwt.txt` — a plain text file containing your provisioning JWT (just the token string, no newline)
`jwt.txt` is uploaded as a package file so Deploy distributes it to the endpoint before any commands run. The JWT never appears in the command body and is therefore not visible to admins browsing package details.
### System requirements
* **Architecture:** x64
* **Minimum OS:** macOS 13.0
### Install operation
Enable the **Install** operation and ensure **Require Source Files** is selected. Add three sequential Run Commands:
**Command 1 — Stage the JWT**
```shell theme={null}
install -m 400 jwt.txt /var/tmp/origin-provisioning-jwt
```
This copies `jwt.txt` to the path the postinstall expects, with permissions set to read-only by owner (root/SYSTEM). Success code: `0`.
**Command 2 — Install Origin**
```shell theme={null}
installer -pkg Origin.pkg -target /
```
Success code: `0`.
**Command 3 — Clean up the JWT**
```shell theme={null}
rm -f /var/tmp/origin-provisioning-jwt
```
Success code: `0`.
If Command 1 or 2 fails, Deploy will not proceed to the next command. The cleanup in Command 3 also runs on success — if the installer itself fails and leaves the JWT file behind, note that the file has mode 400 (root read-only) so it is not readable by other processes.
### Installation requirements
This ensures the package only runs on Macs that do **not** already have Origin installed:
| Attribute | Operator | Value |
| - | - | - |
| File Path | does not exist | `/Applications/Origin.app` |
### Install verification
This confirms Origin installed successfully:
| Attribute | Operator | Value |
| - | - | - |
| File Path | exists | `/Applications/Origin.app` |
### Save the package
Click **Create Package** and wait for **Status** to reach **100%** before deploying.
## Step 7 — Create the Deployment
1. Go to `Modules → Deploy → Deployments` and click **New Deployment**
2. Select **Software Package** and choose `Origin Agent - Install (macOS)`
3. Select **Install** as the operation
4. In **Endpoints to Target**, select the `Origin Profiles Installed` computer group
5. Set **Deployment Type** to **Ongoing** — this ensures newly enrolled Macs automatically receive the agent once their profile reaches Installed status
6. Configure a maintenance window if required by your change management policy
7. Click **Deploy**
**The ongoing deployment plus the dynamic computer group makes this fully zero-touch for new Macs going forward.** A Mac enrolls in Device Management → the profile pushes via MDM → the profile reaches Installed → the Mac joins the `Origin Profiles Installed` group → Deploy fires automatically.
## Step 8 — Verification
Run these checks on a target endpoint after the deployment completes.
### Deploy job status
Open the deployment in `Modules → Deploy → Deployments` and confirm the endpoint shows **Installed** status.
### Profile installed
```shell theme={null}
sudo profiles show -all | grep -i "origin"
```
Should return the Origin privacy profile.
### Agent process running
```shell theme={null}
pgrep -x origin
```
Returns a PID when the agent is running.
### JWT cleaned up
```shell theme={null}
ls /var/tmp/origin-provisioning-jwt
```
Expected: `No such file or directory`
### Agent log
```shell theme={null}
cat /Library/Origin/logs/agent.log.$(date -u +%Y-%m-%d)
```
Confirms agent started cleanly and registration succeeded.
### Origin console
In the Origin console, click **Computers** and search for the target hostname. A successfully registered endpoint will appear with a recent snapshot time and its detected AI agents populated.
## Step 9 — Troubleshooting
### Profile shows Failed or Pending in Device Management
Check the setting status on the collection's Devices tab.
* **AllowedTeamIdentifiers conflict** — the profile XML was modified or recreated using a payload editor. Re-upload the raw `.mobileconfig` from the deployment package.
* **Profile stuck Pending** — trigger an MDM check-in from the device's Endpoint Details page using **Deploy Action → Refresh Device Data**, or wait for the next scheduled check-in.
### Mac not appearing in the `Origin Profiles Installed` computer group
Run the sensor question manually in Interact to confirm the output format matches the regex:
```text theme={null}
Get Device Management - Settings Installation Status from all machines with Computer Name equals
```
If the profile name in the output differs from `Origin - Privacy`, update the computer group regex to match the actual name.
### JWT prompt appears during install (non-silent install)
The installer postinstall did not find the staged JWT. Check:
1. Command 1 (`install -m 400 jwt.txt /var/tmp/origin-provisioning-jwt`) completed with exit code 0 — check the Deploy job log
2. `jwt.txt` was uploaded to the package files and **Require Source Files** is enabled on the Install operation
3. `jwt.txt` contains only the JWT string with no trailing newline or whitespace
### Deploy package shows Not Applicable
The Installation Requirements rule (`/Applications/Origin.app` does not exist) is evaluating as not met — meaning Origin is already installed on the endpoint. Check the endpoint in the Origin console to confirm whether it is already registered.
### Origin not appearing in Origin console after install
* Confirm outbound HTTPS (port 443) from the endpoint to the Origin cloud backend is not blocked by a network proxy or firewall
* Check the agent log: `cat /Library/Origin/logs/agent.log.$(date -u +%Y-%m-%d)`
* Confirm the JWT in `jwt.txt` was valid and had not expired at install time
## Step 10 — Maintenance
### Updating the Origin agent
1. Download the new `Origin.pkg` from the Origin console
2. Edit the `Origin Agent - Install (macOS)` package in Deploy — replace `Origin.pkg` in Package Files and increment the version
3. Update the **Install Verification** if the app version changes
4. The ongoing deployment automatically pushes the update to enrolled endpoints
### Rotating the provisioning JWT
1. Obtain the new JWT from the Origin console under `Endpoints → Connect`
2. Create a new `jwt.txt` containing the new token
3. Edit the Deploy package — replace `jwt.txt` in Package Files and increment the version
4. Existing registered agents are not affected — they maintain their own session credentials after initial registration. Only endpoints receiving a fresh install will use the updated JWT.
### Removing the agent
A `Resources/uninstall.sh` script is bundled inside the app:
```shell theme={null}
/Applications/Origin.app/Contents/Resources/uninstall.sh
```
Add a **Remove** operation to the Deploy package using this command and deploy to the target computer group.
### Mac Device Enrollment deprecation
Tanium Mac Device Enrollment is deprecated as of December 2025 and sunsets September 2026. If your environment currently uses Mac Device Enrollment, migrate to Tanium Device Management before implementing this guide. See the *Tanium Endpoint Management for Mobile User Guide* for migration steps.
# Deploy the Origin Agent via MDM: Jamf, Intune, Tanium
Source: https://docs.originhq.com/getting-started/mdm-overview
Push the Origin agent to your entire macOS or Windows fleet using Jamf Pro, Microsoft Intune, or Tanium — one configuration profile and a provisioning token.
The following MDM deployment methods have been tested and fully documented. Each method has its own page with detailed step-by-step instructions:
1. [**Windows Origin Agent via Intune**](/getting-started/windows-via-intune)
2. [**macOS Origin Agent via Intune**](/getting-started/macos-via-intune)
3. [**macOS Origin Agent via Jamf**](/getting-started/macos-via-jamf)
4. [**macOS Origin Agent via Tanium**](/getting-started/macos-via-tanium)
## MDM Configuration Profile
All three macOS deployment guides use the same privacy preferences (PPPC) profile. It pre-grants the Origin agent **Full Disk Access** and **Endpoint Security** access, so the agent registers silently with no user-facing permission dialogs.
Save the contents below to a file named exactly `origin-privacy.mobileconfig`.
```xml origin-privacy.mobileconfig theme={null}
PayloadContent
PayloadType
com.apple.TCC.configuration-profile-policy
PayloadIdentifier
com.origin.agent.pppc
PayloadUUID
B2C3D4E5-F6A7-8901-BCDE-F23456789012
PayloadVersion
1
PayloadDisplayName
Origin Privacy Preferences
PayloadDescription
Grants Origin Full Disk Access and Endpoint Security permissions.
Services
SystemPolicyAllFiles
Identifier
com.origin.agent
IdentifierType
bundleID
CodeRequirement
identifier "com.origin.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "D3C73MWD7Y"
Allowed
StaticCode
EndpointSecurityClient
Identifier
com.origin.agent
IdentifierType
bundleID
CodeRequirement
identifier "com.origin.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "D3C73MWD7Y"
Allowed
StaticCode
PayloadDisplayName
Origin - Privacy Preferences
PayloadDescription
Pre-grants Origin Full Disk Access and Endpoint Security permissions.
PayloadIdentifier
com.origin.agent.profile.pppc
PayloadOrganization
Origin Security
PayloadType
Configuration
PayloadUUID
C3D4E5F6-A7B8-9012-CDEF-345678901234
PayloadVersion
1
PayloadScope
System
```
Upload the file to your MDM as a **raw `.mobileconfig`**. Do not recreate it in Jamf's, Intune's, or Tanium's built-in payload editor — they rewrite the XML and break the code requirement that makes the permission grants work.
The install script each guide needs is included inline on that guide's own page.
For manual installation instructions on macOS and Windows, refer to the [macOS Agent Installation](/getting-started/macos-installation) and [Windows Agent Installation](/getting-started/windows-installation) pages. MDM deployment is recommended for fleet-scale rollouts where per-endpoint manual installation is not practical.
# Capture Microsoft 365 Copilot Activity in Origin
Source: https://docs.originhq.com/getting-started/microsoft-365-copilot
Capture Microsoft 365 Copilot prompts and responses across Word, Excel, Outlook, Teams, and Copilot Chat directly from Microsoft's cloud APIs, no agent.
Origin captures Microsoft 365 Copilot activity by reading it directly from Microsoft's own cloud APIs. It pulls Copilot prompts and responses — across Word, Excel, Outlook, Teams, and Copilot Chat — and lands them in the same AI activity record as everything else Origin observes, attributed to the person who ran them.
The [Microsoft Entra ID directory integration](/product/entra-id-setup) is a prerequisite. It is what authorizes Origin, through a single tenant-wide admin consent, and provides the identity mapping that attributes each Copilot interaction to a person. But the Copilot data itself doesn't come from the directory — it comes from a set of **Microsoft 365 and Microsoft Purview APIs** described below. There is no separate app, key, or credential to configure.
## What it adds
With Copilot capture on, Origin pulls each licensed user's Microsoft 365 Copilot prompts and responses and threads them into the same traces, analytics, and inventory as your other AI activity. Copilot usage can then be investigated alongside Claude, ChatGPT, and everything Origin captures on the endpoint — attributed to the right person and scoped to the users your directory integration syncs.
It reads Copilot interaction history and its associated audit and usage signals only. Origin does not read the underlying documents, mailboxes, or chats that Copilot was working with, and it never writes to or changes anything in your Microsoft 365 tenant.
## How Origin acquires Copilot data
Copilot capture reads from several Microsoft services, all authorized by the one admin consent you grant on the Entra integration. No permission here is entered into Origin — each is a scope on Microsoft's side that the consent grants to Origin's managed application.
| Consent permission | Microsoft service / API | What Origin gets |
| - | - | - |
| Read all AI enterprise interactions | **Microsoft 365 Copilot interaction export API** (Microsoft Graph — `copilot/users/{id}/interactionHistory/getAllEnterpriseInteractions`) | The actual interaction content: user prompts and Copilot responses, per user, across Word, Excel, PowerPoint, Outlook, Teams, and Microsoft 365 Copilot Chat (BizChat), with timestamps, session/request IDs, and the app each interaction happened in. |
| Read all audit log data | **Microsoft Purview** unified audit log (Copilot `CopilotInteraction` records) | The governance context around each interaction: which user, when, where (the host app), the files, emails, and sites Copilot accessed to answer, their sensitivity labels, whether the web or a plugin was used, and safety signals such as jailbreak / cross-prompt-injection detections. |
| Read activity data for your organization | **Microsoft Graph usage reports** | Tenant Copilot usage and adoption metrics that complement the per-interaction record. |
| (directory permissions) | **Microsoft Entra ID / Microsoft Graph** | Users, groups, and group membership — used to attribute each interaction to a person and to scope capture to the right users. |
A few things follow from how these APIs work:
* **The interaction export API is per user and licensing-gated.** Microsoft only returns Copilot interactions for users who hold a valid Microsoft 365 Copilot license, so Origin pulls Copilot data only for your synced, Copilot-licensed users.
* **Purview auditing must be on.** Copilot interactions are written to the unified audit log automatically as part of Microsoft Purview Audit (Standard) — as long as auditing is enabled for your tenant, and it is by default for most tenants, there is nothing extra to turn on.
* **Copilot Studio agents are out of scope.** Microsoft's interaction export API does not return interactions from custom agents built in Copilot Studio.
Microsoft documents these surfaces at [aiInteractionHistory: getAllEnterpriseInteractions](https://learn.microsoft.com/en-us/graph/api/aiinteractionhistory-getallenterpriseinteractions) and [Audit logs for Copilot and AI applications](https://learn.microsoft.com/en-us/purview/audit-copilot).
## Before you start
* A connected [Microsoft Entra ID directory integration](/product/entra-id-setup). Set that up first — Copilot capture depends on it for authorization and identity mapping.
* **Microsoft 365 Copilot licensing** for the users whose activity you want to capture. Microsoft's interaction export API only returns data for licensed users.
* **Microsoft Purview auditing enabled** for your tenant, which is on by default for most tenants. This is what records Copilot interactions to the audit log.
* An **Origin admin**, to enable capture and run the readiness check.
## Setup
If you haven't already, follow [Microsoft Entra ID Setup](/product/entra-id-setup) to connect your directory.
When you grant admin consent, the permission list already includes **Read all AI enterprise interactions** — that's what makes Copilot capture possible. No extra consent is needed later.
1. Sign in to the Origin dashboard at [dashboard.originhq.com](https://dashboard.originhq.com/) as an admin.
2. Open **Admin → Data Sources** and find **Microsoft 365 Copilot capture**.
3. Each connected Microsoft Entra directory appears as its own card, showing **Connected**. Find the directory you want and turn on **Capture Copilot activity**.
Capture is scoped to that directory's synced users, so it follows the sync scope — whole tenant or selected groups — that you set on the directory integration.
Enabling capture reveals a **Readiness** section. Capture is on but **blocked until the Microsoft-side prerequisites pass**.
1. Click **Re-check**, shown as **Check readiness** before capture is enabled. This makes live calls to the Microsoft APIs above to confirm capture will work — that the admin consent covers the required scopes, that Copilot interaction data is retrievable, and that the audit and usage data are available for the tenant.
2. Review the results. Once the prerequisites pass, capture starts.
If the check reports a problem, resolve it — most often Copilot licensing or incomplete admin consent, see [Troubleshooting](#troubleshooting) — and press **Re-check** again.
## What to expect
Once readiness passes, Copilot activity flows continuously into your traces, analytics, and inventory, attributed to each person, alongside the rest of your captured AI activity. There is nothing to export and no schedule to manage.
## Changing or removing capture
* **Pause capture** — turn off **Capture Copilot activity** for a directory. New Copilot activity stops syncing; data already in Origin is unaffected.
* **Re-scope** — capture follows the directory's sync scope. To change which users are covered, adjust the **Sync scope** on the [directory integration](/product/entra-id-setup).
* **Remove entirely** — removing the Entra directory integration also ends Copilot capture, since the two share the same consent.
## Troubleshooting
| Symptom | Likely cause | Resolution |
| - | - | - |
| No **Microsoft 365 Copilot capture** card, or it isn't **Connected** | No connected Entra directory integration | Connect the [Entra directory integration](/product/entra-id-setup) first. |
| Capture is on but shows "blocked until the required prerequisites pass" | Readiness hasn't been run, or a prerequisite failed | Click **Re-check** and resolve any reported issue. |
| Readiness fails on permissions / consent | Admin consent was partial, or the AI interactions permission wasn't granted | Re-run admin consent on the directory integration with an eligible admin, then **Re-check**. |
| Readiness passes but no Copilot activity appears | Users aren't Copilot-licensed, aren't in scope, or haven't used Copilot recently | Confirm Copilot licensing and that the users are within the directory's sync scope, then use Copilot and wait for the next sync. |
| Readiness fails on auditing | Microsoft Purview auditing is turned off for the tenant | Enable auditing in the Microsoft Purview portal, then **Re-check**. |
| Copilot Studio agent activity is missing | Microsoft's interaction export API doesn't return Copilot Studio agent interactions | This is a Microsoft API limitation, not an Origin configuration issue. |
## What Origin accesses
* **Read-only** access to **Microsoft 365 Copilot interaction history** (prompts and responses) for the directory's synced, Copilot-licensed users, through the Microsoft Graph interaction export API.
* **Read-only** access to the **Microsoft Purview Copilot audit records** for those interactions — the identity, timing, host app, accessed resources, sensitivity labels, and safety signals — and to tenant **Copilot usage reports**.
* All of the above is authorized by the single tenant-wide admin consent granted on the Entra integration. Nothing is entered into Origin.
* **No access** to the documents, mailboxes, or chats behind those interactions, and no ability to write to or change anything in your Microsoft 365 tenant.
# Create and Manage Origin Agent Provisioning Tokens
Source: https://docs.originhq.com/getting-started/provisioning-tokens
Create and manage Origin provisioning tokens from Endpoints → Connect → Tokens. Each token has an expiry and a use limit and is used during installation.
Every Origin agent installation requires a provisioning token to register itself with your tenant. Without a valid token, an installed agent cannot connect to Origin or begin reporting telemetry. You create and manage tokens from **Endpoints → Connect**, then click **Tokens** in the top-right of the panel — or [jump straight there](https://dashboard.originhq.com/?mode=endpoints\&adminView=tokens).
![The Provisioning Tokens list under Endpoints → Connect → Tokens, showing status, created/expires dates, use count, creator, and token ID for each token.]()
## What is a provisioning token?
A provisioning token is a signed JWT that proves to the Origin backend that an agent installation is authorized to register under your tenant. Think of it as the agent's enrollment credential. You supply it once during installation — interactively when running the installer manually, or silently when deploying via MDM. After the agent has registered, the token is no longer needed for that endpoint's ongoing operation.
One token can register **several** endpoints, but not unlimited ones. Each token carries a use limit and an expiry — see below. Many organizations create one token per deployment wave so a batch can be revoked independently.
## The token list
| Column | Description |
| - | - |
| **Status** | `Active` or `Revoked` |
| **Created** | When the token was created |
| **Expires** | When the token stops being valid |
| **Used** | Registrations consumed against the token's limit, shown as `used / limit` |
| **Created by** | The user who created it |
| **Token ID** | The token's unique identifier |
**Tokens expire and are use-limited.** A token shows an explicit expiry date and a `used / limit` count — for example `1 / 10`. Once either the expiry passes or the limit is reached, that token can no longer register new endpoints and your deployment will start failing.
Check both before a large rollout, and confirm the limit is high enough for the number of endpoints in the wave.
Use **Columns** to change which columns are visible, and the search box to filter the list.
## Creating a token
Sign in at [dashboard.originhq.com](https://dashboard.originhq.com/) and click **Endpoints** in the far-left rail.
Select **Connect**, then click **Tokens** in the top-right of the panel.
Click **Create Token**.
Copy the token value as soon as it appears and store it in your organization's secrets manager, MDM configuration store, or credential vault.
## Using the token during installation
How you supply the token depends on your deployment method.
### Manual installation
When you run the installer interactively on a macOS or Windows endpoint, the installer prompts you for the provisioning token. Paste the value you copied from the console and complete the installation.
### MDM deployment
For large-scale deployments, your MDM injects the token silently as part of the install script or configuration profile.
* **Windows** — passed as an MSI property: `PROVISIONING_JWT=`
* **macOS** — staged to a file the package's postinstall reads, so no user interaction is required
See the [MDM Deployment guides](/getting-started/mdm-overview) for platform-specific configuration, and [Windows Install](/getting-started/windows-installation) for the full `msiexec` syntax.
## Revoking a token
Find the token in the list and click **Revoke** on its row. The token is invalidated immediately and can no longer register new endpoints. Revoked tokens remain in the list with a `Revoked` status for audit purposes.
Revoking a token does **not** disconnect or deregister endpoints that already registered with it. It only prevents the token from being used to register *new* endpoints. Existing enrolled endpoints continue to report telemetry normally.
To rotate: create a replacement token, update your MDM configuration and deployment scripts to use the new value, test a deployment, then revoke the old token.
## Security best practices
Treat a provisioning token like a password. Anyone holding a valid, unexpired token with remaining uses can register new endpoints against your tenant.
* **Do not commit tokens to source control.** Even in private repositories, secrets in version history are a common source of credential leaks. Use environment variables or a secrets manager.
* **Scope tokens per deployment wave** so you can revoke one batch without disrupting others.
* **Limit distribution.** Store the value in your MDM's secure parameter store rather than in plain-text scripts.
* **Revoke tokens you no longer need**, rather than letting them sit until expiry.
* **Watch the `used / limit` count** on tokens backing an active rollout, so you notice before a wave starts failing.
# My Account: Access Scope, Password, and Local Browser Data
Source: https://docs.originhq.com/getting-started/settings-view
Manage your own Origin account from My Account: view your access scope, change your password, and clear cached chat history, workflows, and MCP credentials.
**My Account** covers settings that are personal to you rather than shared across the tenant: your own access scope, your password, and data cached in the browser you're currently using. Open it by clicking your avatar in the bottom-left corner of the console and selecting **My Account**.
My Account is separate from **Admin**. Admin holds tenant-wide configuration that affects every user; My Account only affects your own sign-in and this browser. The page banner reminds you: *"These controls affect your sign-in, preferences, or locally stored browser data. They do not change organization-wide policy."*
## Identity — Your access
The first card reports the scope of your own access, for example *"Covers the whole tenant · 100 endpoints."*
This card is informational. It describes your intended scope — it is not a filter on the data shown elsewhere in the console.
## Account — Change Password
Set a new password from the **Current password**, **New password**, and **Confirm new password** fields, then click **Update password**. New passwords must be at least 8 characters.
This only applies to local password accounts. Users who sign in via SSO / WorkOS manage credentials at their identity provider.
## Local storage — Clear local data
Wipes locally-cached data from the browser you're using, without signing you out. This affects that browser only; server-side state is unchanged. Each row has its own **Clear** button.
| Item | What it clears |
| - | - |
| **Chat history** | Conversations and prompts saved in this browser. Local kernels, canvases, pins, and pending cloud-recovery data are preserved. |
| **Workflows** | Workflow definitions and run history saved in this browser. |
| **MCP credentials** | OAuth tokens and API keys for Linear, Notion, Zapier, and other MCP servers. |
## Fleet and integration settings have moved
Fleet-wide agent settings (tray icon visibility, OTLP collector port) and AI data source integrations (Anthropic Compliance API key, Microsoft 365 Copilot capture) used to live on this page. They're now tenant-wide configuration, not personal account settings, so they've moved:
Fleet-wide agent settings, under **Endpoints → Configuration**.
AI provider integrations, under **Admin → Data Sources**.
# Invite Users and Assign Roles in the Origin Console
Source: https://docs.originhq.com/getting-started/user-management
Invite team members to your Origin tenant from Admin → Access, assign one of the eight built-in roles, and manage user access over time.
Origin ships eight built-in roles. This page lists what each role covers and how to invite people into your tenant.
## The eight built-in roles
| Role | Description |
| - | - |
| **Tenant Admin** | Full administrative access — can manage users, endpoints, integrations, and tenant settings. |
| **SecOps** | SOC analyst — broad read access plus row-level analytics with prompt content stripped; no sensitive data. |
| **Detection Engineer** | Detection content owner — read access including raw event and AI session content. |
| **IT / Fleet Admin** | Fleet administrator — write access; no raw event content. |
| **Viewer** | Auditor / read-only stakeholder. |
| **Vendor Support** | External support engineer — fleet/operational health for troubleshooting; no monitored content. |
| **Security Engineering** | Platform/integration engineer — manages integrations and platform config; no monitored-data read. |
| **No Data Access** | Login and navigate only — holds no permissions; sees no tenant or operational data. |
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).
## 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.
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.
## Choosing a role
Start from least privilege and add capability only where a person's job requires it.
* **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.
## The User Management view
Open **Admin → Access** 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**.
Only **Tenant Admin** can invite users, remove users, or change a user's role.
## Inviting a user
Sign in at [dashboard.originhq.com](https://dashboard.originhq.com/), click **Admin** in the far-left rail, then select **Access**.
Click **Invite user** at the top right.
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.
Click **Send invite**. The user receives a WorkOS invitation email and joins the organization once they accept.
The invite dialog collects an email and a role only.
# Verify the Origin Agent Is Running and Capturing AI
Source: https://docs.originhq.com/getting-started/verifying-installation
Confirm the Origin agent is installed, healthy, and capturing AI activity on macOS and Windows using tray diagnostics, service checks, and test prompts.
This document details the steps to confirm the Origin Observability Agent is installed, healthy, and capturing AI activity on macOS and Windows endpoints.
## Contents
1. [UI and Diagnostic Report](#1-ui-and-diagnostic-report)
2. [Verify Services and Processes](#2-verify-services-and-processes)
3. [Generate Test Activity](#3-generate-test-activity)
4. [Verify activity in the Origin Platform](#4-verify-activity-in-the-origin-platform)
## 1. UI and Diagnostic Report
The Origin Agent runs a small UI accessible from the **system tray** (Windows) or **menu bar** (macOS). The icon color is the fastest health check:
| Icon | Status |
| - | - |
| **Green** | Healthy — agent running, registered, capturing |
| **Yellow** | Degraded — running but one or more checks are failing |
| **Red** | Error — agent stopped or unregistered |
Click the icon to open the menu. From here:
* **Diagnostic Report** — runs a full self-test (registration, mTLS credentials, backend reachability, entitlements). Every line should read **OK**.
* **Open Log Folder** — opens the runtime log directory:
* Windows: `C:\ProgramData\Origin\Agent\Logs\`
* macOS: `/Library/Origin/logs/`
If the icon is green and the Diagnostic Report comes back clean, the agent is healthy locally.
## 2. Verify Services and Processes
Both the **Origin Agent** and the **Origin Watchdog** must be running. The watchdog starts at boot and brings up the agent.
### Windows (elevated PowerShell)
```powershell theme={null}
Get-Service OriginWatchdog, OriginAgent
```
Both should report **Running**.
### macOS
```bash theme={null}
sudo launchctl list | grep origin
```
Two entries should return: `com.origin.watchdog` and `com.origin.agent`, each with a non-zero PID.
### Cross-check in the Origin Platform
Sign in to the **Origin Platform**, open the **Registered Endpoints** view, and confirm your endpoint shows a recent "Snapshot Time". If the endpoint is present here, it has registered successfully with the Origin Platform.
## 3. Generate Test Activity
Origin captures AI activity by three different methods, and each has to be tested separately — a passing test in one track says nothing about the others. Run the track that matches what you are verifying, or all three for a full check.
| Track | What it proves | Requires |
| - | - | - |
| **3.1 Agent capture** | The agent's OpenTelemetry collector and application hooks are working **on this endpoint** | Origin agent installed |
| **3.2 Anthropic API integration** | Claude chat activity is flowing from Anthropic's Compliance API | Compliance Access Key configured in Settings |
| **3.3 Microsoft 365 Copilot** | Copilot activity is flowing from Microsoft's cloud APIs | Entra ID directory connected and Copilot capture enabled |
Embed a unique token in each test prompt — e.g. `ORIGIN-VERIFY-` or a unique UUID — to make the prompts trivially searchable.
### Sample prompts
A few industry-recognized prompts that exercise different capture archetypes. Use these in any of the tracks below:
* **Summarization** — *"`ORIGIN-VERIFY-20260513` — summarize the NIST AI Risk Management Framework (AI RMF 1.0) in three bullets."*
* **Code generation** — *"`ORIGIN-VERIFY-20260513` — write a Python function that validates an IPv4 CIDR string."*
* **Rewrite / tone shift** — *"`ORIGIN-VERIFY-20260513` — rewrite this for a non-technical executive: \[paste a short paragraph]."*
* **Open Q\&A** — *"`ORIGIN-VERIFY-20260513` — list the OWASP Top 10 for LLM Applications."*
* **Data analysis** — *"`ORIGIN-VERIFY-20260513` — given this CSV: \[paste 5–10 rows], identify outliers and explain your reasoning."*
### 3.1 Agent capture — OpenTelemetry and application hooks
These applications are captured locally by the agent on the endpoint. No tenant-level integration is involved, so this is the only track that proves the install you just performed is working.
Pick **one or two** of the following that are available on the verified endpoint:
1. Open **Claude Code** — the CLI or the desktop app — on the verified endpoint.
2. Send a verification prompt from the list above.
3. Send a follow-up to generate a multi-turn session.
1. Open **Claude Cowork** on the verified endpoint.
2. Send a verification prompt from the list above.
3. Send a follow-up to generate a multi-turn session.
1. Open the **ChatGPT desktop app** on the verified endpoint. Chat, Work, and Codex surfaces are all captured.
2. Send a verification prompt from the list above.
3. Send a follow-up to generate a multi-turn session.
1. Open a terminal on the verified endpoint and start the **Codex CLI**.
2. Send a verification prompt from the list above.
3. Send a follow-up to generate a multi-turn session.
Track 3.1 is the one that validates **this endpoint**. Tracks 3.2 and 3.3 read from the provider's cloud, so they report activity tenant-wide — including from devices with no agent installed — and a pass there does not mean the local agent is capturing.
### 3.2 Anthropic API integration — Claude chat
Claude chat activity is not captured on the endpoint. It is pulled from Anthropic's Compliance API and covers both surfaces:
1. **Browser** — sign in to [claude.ai](https://claude.ai), send a verification prompt, then send two or three follow-ups to populate a meaningful session.
2. **Claude Desktop Chat** — open the Claude desktop app, use the **Chat** surface, and send a verification prompt.
This track only produces results once the **Compliance Access Key** is configured under **Admin → Data Sources**. If it isn't, no claude.ai or Claude Desktop Chat activity will appear regardless of how many prompts you send. See [Claude Enterprise](/product/claude-enterprise).
### 3.3 Microsoft 365 Copilot
Copilot activity is read from Microsoft's own cloud APIs, not from the endpoint. Exercise one or more of the surfaces:
1. **Office applications** — open Word, Excel, or PowerPoint, click the **Copilot** icon in the ribbon, send a verification prompt, then send a follow-up.
2. **Copilot on the web** — browse to [copilot.microsoft.com](https://copilot.microsoft.com), sign in, send a verification prompt, and send a follow-up in the same conversation.
3. **Teams and Outlook** — use the Copilot pane in either application and send a verification prompt.
This track requires the Entra ID directory integration to be connected, **Capture Copilot activity** enabled for that directory, and the readiness check passing. See [Microsoft 365 Copilot](/getting-started/microsoft-365-copilot).
## 4. Verify activity in the Origin Platform
Allow 1–2 minutes for events to propagate to the Platform, then:
1. Open the **Origin Platform**.
2. Locate the endpoint in All Endpoints view (this is the default landing page) and click it.
3. Confirm the endpoint's activity bar at the top of the page now shows recent prompt activity — colored ticks indicating prompts captured within the test window.
4. In the **Resource Overview** graph, confirm the applications you exercised appear as nodes:
* **Track 3.1** — Claude Code, Claude Cowork, ChatGPT, or Codex, depending on what you ran.
* **Track 3.2** — **Claude**.
* **Track 3.3** — **M365 Copilot**, and often **ChatGPT** as well (M365 Copilot's underlying model surface frequently appears under this label).
Activity from tracks 3.2 and 3.3 is sourced from the provider's cloud rather than the agent, so look for it across the tenant rather than expecting it on the endpoint you just verified.
If the activity bar is empty after a few minutes, re-run the Diagnostic Report from the tray icon and check that every line reads **OK**, then consult the agent runtime logs. For the full matrix of which applications are captured by which method, see [AI Provider Support](/getting-started/ai-providers).
# What is Origin? Endpoint AI Observability Explained
Source: https://docs.originhq.com/getting-started/what-is-origin
Origin is an endpoint AI observability platform that inventories, monitors, and audits every AI agent running on Windows and macOS endpoints at scale.
Origin inventories and monitors every AI agent on your endpoints, giving you complete audit trails, behavioral baselines, and incident investigation tools.
Origin is an endpoint AI observability platform that inventories, observes, and measures the usage of AI agents at scale. It gives your security and operations teams the operational intelligence they need to understand the state of AI across your organization — from individual prompts all the way up to fleet-wide behavioral patterns. This visibility is the foundation for everything from making defensible AI investment decisions to maximizing adoption and efficiency without compromising security.
## How Origin works
Origin installs a lightweight agent on each managed endpoint (macOS or Windows). That agent collects AI inventory and event data and streams it back to your Origin tenant.
Capture happens at the application layer, not the network layer. Origin collects AI event data two ways on the endpoint:
* **OpenTelemetry** — the agent configures each AI tool's native OTel exporter to report to a local collector on the endpoint, then forwards that telemetry to your tenant.
* **Application-level hooks** — for applications that expose no telemetry of their own.
Activity that never touches an endpoint — `claude.ai` in a browser, Microsoft 365 Copilot — is read directly from the provider's own cloud APIs instead. See [AI Provider Support](/getting-started/ai-providers) for which applications are captured by which method.
The console then surfaces that data as searchable sessions, activity clusters, behavioral baselines, and an interactive chat interface — so you can investigate incidents, satisfy compliance requirements, and understand how AI is actually being used across your fleet.
## Key capabilities
Trace any security incident or policy violation back to its origin prompt. Origin gives you a full timeline of every AI interaction on every endpoint, so you can reconstruct exactly what happened, when, and who was responsible.
Maintain a complete, tamper-evident record of every prompt sent and every AI agent decision made across your organization. Use this audit trail to satisfy internal reviews, regulatory inquiries, or eDiscovery requests.
Automatically discover and catalog every AI tool and computer-use agent running on your endpoints — including shadow AI you didn't know existed. No manual asset tracking required.
Understand what "normal" AI usage looks like for each user, team, or endpoint. Origin uses this baseline to surface anomalies — unusual prompt volumes, new AI providers, or out-of-pattern activity — before they become incidents.
## The Origin agent
The Origin agent is a lightweight background service that runs on each managed endpoint. It collects AI event data from the applications running on that host — via their OpenTelemetry exporters and, where those don't exist, application-level hooks — and streams it to your Origin tenant in real time, encrypted in transit.
The agent is designed to be invisible to end users by default: it runs silently, has no user-facing UI unless you choose to show the tray icon, and picks up configuration your administrators push from the console on each heartbeat.
## What you can do with Origin
Once Origin is deployed across your fleet:
* **Complete AI inventory** — every AI agent installed and running on your managed devices, discovered automatically with no manual asset tracking.
* **Shadow AI discovery** — every AI provider in use across your organization, including tools your IT and security teams haven't approved.
* **Incident investigation** — replay the full prompt-and-response timeline for any session on any endpoint.
* **Activity clustering** — identify what kinds of work employees are offloading to AI tools.
* **Behavioral baselines** — receive alerts when usage patterns deviate from the norm.
* **Natural-language fleet queries** — ask questions of your own telemetry data through the Origin chat interface.
# Installing the Origin Agent on Windows: MSI Silent Deploy
Source: https://docs.originhq.com/getting-started/windows-installation
Silently deploy the Origin agent on Windows using the MSI installer with a provisioning JWT, with optional enhanced logging and OTEL configuration.
The MSI installer is available from the Origin console. As noted in the prerequisites, this install option requires Microsoft Visual C++ to be installed. An `.exe` installer is also available upon request and will install Microsoft Visual C++ automatically if it is missing.
## Silent Install (MSI)
```bat theme={null}
msiexec /i origin-installer-x_y_z-windows-x64.msi /quiet PROVISIONING_JWT= INSTALL_WINDIVERT=0
```
## Silent Install with Enhanced Logging
```bat theme={null}
msiexec /i origin-installer-x_y_z-windows-x64.msi /quiet /norestart /l*v "C:\ProgramData\Origin\Agent\Logs\msi-install.log" PROVISIONING_JWT= INSTALL_WINDIVERT=0
```
**`INSTALL_WINDIVERT=0`**
This property is included on every install. Setting it requires a corresponding configuration change by your Origin TAM — coordinate with them before deploying at scale.
## Log Locations
| Log | Path |
| - | - |
| Install Log | `C:\ProgramData\Origin\Agent\Logs\install.log` |
| Detailed MSI Log | `%temp%\Origin_Observability_Agent_xxxx.log` |
| MSI Component Log | `%temp%\Origin_Observability_Agent_xxxx_OriginAgentMsi.log` |
| Agent Runtime Logs | `C:\ProgramData\Origin\Agent\Logs\` |
## System Tray Icon
The Windows Origin install creates a system tray icon that provides visibility into the overall health of the agent, allows you to run a health diagnostic report, and provides quick access to agent logging.
For a full end-to-end verification workflow, see [Verifying Agent Installations](/getting-started/verifying-installation).
# Deploy the Origin Windows Agent via Microsoft Intune
Source: https://docs.originhq.com/getting-started/windows-via-intune
Push the Origin Windows agent MSI to managed endpoints via Intune — upload as a line-of-business app and pass the JWT as an install argument.
A step-by-step walkthrough for packaging and pushing the Origin agent to managed Windows endpoints.
## Prerequisites — Before you start
Confirm the following before proceeding:
* **Intune admin role** (or a scope that permits app creation and assignment).
* **A valid Origin provisioning JWT** (install token) — obtain from the Origin console under **Endpoints → Connect**.
* **An Entra ID security group** scoped to your target devices.
* **The Origin installer MSI** — download from the Origin console under **Endpoints → Connect**.
**Where to find it**
Both the installer binary and the provisioning JWT live in the same place in the Origin console: **Endpoints → Connect**. Download the MSI and copy the provisioning token from that screen before moving to Intune.
## Packaging — Upload the MSI to Intune
Intune accepts the Origin installer as a Windows MSI line-of-business app — no wrapping or prep tool required. Intune auto-populates the product code, version, and basic detection rules from the MSI metadata.
**Line-of-business app**: Upload the MSI directly to Intune. Detection, uninstall, and version tracking are handled automatically via the embedded product code.
**Upload path**: Intune admin center → **Apps → Windows → Add → Line-of-business app** → upload `origin-installer-windows-x64.msi` directly.
## Configuration — Configure the app in Intune
The wizard presents four tabs: **App information**, **Scope tags**, **Assignments**, and **Review + create**. Work through each tab in order.
### 1. App information
Fill in the fields as shown below. Fields not listed here can remain at their defaults.
| Field | Value |
| - | - |
| Select file | `origin-installer-windows-x64.msi` |
| Name | Origin Observability Agent |
| Description | Origin Observability Agent |
| Publisher | Origin |
| App install context | Device |
| Ignore app version | No |
| Command-line arguments | `PROVISIONING_JWT="install_token_here" INSTALL_WINDIVERT=0` |
| Category | No Category |
| Show as featured app | No |
**Command-line argument note**
Replace `install_token_here` with the JWT from **Endpoints → Connect** in the Origin console — the same screen where you downloaded the MSI. Keep the quotes around the token value. Do not include `msiexec` or `/qn`; Intune constructs the full install command automatically.
`INSTALL_WINDIVERT=0` is included on every install and requires a corresponding configuration change by your Origin TAM — coordinate with them before deploying at scale.
### 2. Scope tags
| Field | Value |
| - | - |
| Scope tags | Default |
### 3. Assignments
| Group mode | Group | End user notifications | Availability | Deadline | Restart grace period |
| - | - | - | - | - | - |
| Required → Included | Your target device group | Show all toast notifications | As soon as possible | As soon as possible | Disabled |
**Rollout hygiene**
Start with a small pilot group (2–5 test devices), validate registration, then broaden to your full target group.
**Note:** Required will force the Origin agent to install on any targeted system. If you'd like to make Origin available via Company Portal, assign your group instead under "Available for enrolled devices" and add users (not computers). This will make the Origin app available in Company Portal after targeted users authenticate in Company Portal.
### 4. Review + create
Review all settings, then click **Create**. Intune will process the MSI and make the app available for device assignment. Processing typically takes a few minutes.
## Monitoring and troubleshooting
### Post-deployment checks
1. **Intune admin center → the app → Device install status.** Review successes, failures, and pending counts.
2. **On an endpoint, tail the Intune Management Extension log:** `%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log`
3. **Review the Origin install log on the endpoint:** `C:\ProgramData\Origin\Agent\Logs\install.log`
4. **Confirm the Origin service is running:** `Get-Service -Name Origin*` in PowerShell.
5. **Verify backend registration** in the Origin console — the endpoint should appear with a recent heartbeat.
### Common install failures
| Code / Symptom | Likely Cause | Where to Look |
| - | - | - |
| `1603` | Generic MSI failure | Intune Management Extension log on endpoint; MSI verbose log |
| `0x87D1041C` | Detection rule didn't match post-install | Verify the detection path exists after a manual test install |
| Installer returns 0, agent never registers | Network-layer interception by another endpoint agent (e.g. Netskope WFP/TUN) | Origin-side logs, WinDivert capture status, vendor support channel |
| Token rejected | Expired or malformed JWT | Re-issue from Origin console; confirm copy/paste didn't truncate or add whitespace |
# Troubleshoot Origin Agent Installation on Windows and macOS
Source: https://docs.originhq.com/kb/agent-installation-issues
Diagnose and fix Origin agent installation failures on macOS and Windows, including missing dependencies, network errors, and extension approval issues.
Installation failures typically fall into one of three categories: a missing system dependency on the target endpoint, a network connectivity problem that blocks the registration step, or a healthy agent that isn't yet collecting. Checking the installer exit code or log output will usually point you to the right article below.
The installer exits with error `-1073741515` (`0xC0000135 STATUS_DLL_NOT_FOUND`) because the Microsoft Visual C++ Redistributable is absent. Install the VC++ runtime first, then re-run the Origin installer.
No AI activity appears in the console for a macOS endpoint. Confirm the agent and watchdog are running, and that Full Disk Access is granted to Origin.app.
The agent needs to reach three Origin-hosted endpoints in its region over HTTPS: registration, endpoint, and agent-cdn. If one is blocked by a firewall, proxy, or SASE gateway, installation fails, telemetry stops flowing, or updates stop.
Review the required Visual C++ Redistributable version, necessary outbound endpoints, SASE traffic-steering compatibility notes, and Application Control considerations before deploying the agent at scale.
## Issue types at a glance
### Missing Visual C++ Redistributable (Windows)
When the Microsoft Visual C++ 2015–2022 Redistributable is not present on a Windows endpoint, the Origin agent's binaries cannot load and the installer exits with error `-1073741515`. This is common on fresh OS images, minimal builds, and Windows Server Core installations. The fix is to install the VC++ runtime before running the Origin installer — or to chain it as a prerequisite in Intune, SCCM, or MECM for fleet deployments.
### Agent healthy but no AI events (macOS)
If the agent installed and is running but no AI activity reaches the console, the usual cause is that **Full Disk Access** was never granted to Origin.app. The agent needs it to read application logs and detect AI tooling in user-scoped locations, so without it the agent runs but captures nothing. On MDM-managed fleets this is pre-approved by the PPPC profile.
### Network connectivity failures
During installation, the Origin agent contacts the registration endpoint for its region (for example `registration.prod.originhq.com`) to exchange the provisioning token for a unique client certificate. If that endpoint is unreachable, the install fails and the agent has no certificate. It can't authenticate even after connectivity is restored, so you need to re-run the install. During normal operation, the agent relies on the `endpoint` host for heartbeat, configuration, and AI event reporting. It relies on the `agent-cdn` host for updates and diagnostic uploads. All three need to be reachable on TCP 443, and we recommend excluding them from TLS/SSL inspection. See [Network Connectivity](/kb/network-connectivity) for the full list of hostnames by region and steps to check connectivity.
### Prerequisites and known compatibility issues
Before deploying at scale, confirm that the Visual C++ Redistributable requirement is met, that the three required endpoints for your region are reachable, and that any SASE or Application Control solution is configured to allow the Origin agent to operate correctly. The prerequisites article covers all of these requirements in one place.
# macOS: Origin Agent Installed but No AI Events Captured
Source: https://docs.originhq.com/kb/macos-no-ai-events
If no AI activity appears in the Origin console for a macOS endpoint, confirm the agent is running and that Full Disk Access is granted to Origin.app.
If no AI activity is appearing in the Origin console for a macOS endpoint, there are two things to check.
## 1. Confirm the agent is installed and running
Both the agent and its watchdog must be up. The watchdog starts at boot and is responsible for keeping the core agent alive.
```bash theme={null}
sudo launchctl list | grep origin
```
Two entries should appear — `com.origin.watchdog` and `com.origin.agent` — each with a non-zero PID in the first column.
You can also check the **Origin** icon in the macOS menu bar: a green dot means the agent is healthy. The menu's Diagnostic Report gives a fuller picture and is worth attaching to any support ticket.
## 2. Confirm Full Disk Access is granted
The agent needs Full Disk Access to read application logs and detect AI tooling installed in user-scoped locations. Without it, the agent runs but captures nothing.
1. Open **System Settings → Privacy & Security → Full Disk Access**.
2. Find **Origin.app** in the list.
3. Confirm its toggle is **on**. If Origin.app isn't listed, click **+**, navigate to `/Applications`, select **Origin.app**, and click **Open**, then toggle it on.
The agent starts capturing as soon as the toggle is enabled — no reinstall or reboot required.
On MDM-managed fleets, Full Disk Access is pre-approved by the privacy-preferences (PPPC) profile, so it should already be granted. If it isn't, the profile likely didn't reach the endpoint — see [MDM Overview](/getting-started/mdm-overview).
## Still no events
Attach the Diagnostic Report output and the agent logs to a support ticket:
```bash theme={null}
open /Library/Origin/logs/
```
See [Report Issues](/kb/report-issues) for what to include.
# How to Fully Uninstall the Origin Agent from macOS
Source: https://docs.originhq.com/kb/macos-uninstall
Fully remove the Origin agent and its local state from a macOS endpoint by running the bundled uninstall script from Terminal with a single sudo command.
Removing the Origin agent from macOS takes a single command. The bundled uninstall script handles everything — you do not need to manually remove individual components.
## Run the uninstall script
Open Terminal and run the following command with administrator privileges:
```bash theme={null}
sudo /Applications/Origin.app/Contents/Resources/uninstall.sh
```
The script removes the **Origin agent** and its supporting binaries, along with the launch daemons and local state created during installation.
No reboot is required after the script completes.
After uninstalling, confirm removal by checking that the **Origin icon is no longer present in the macOS menu bar** and that the endpoint no longer reports recent activity under **Endpoints → Overview** in the Origin console. It may take a few minutes for the console to reflect the change.
# Origin Agent Network Connectivity Requirements and Tests
Source: https://docs.originhq.com/kb/network-connectivity
The Origin agent needs outbound HTTPS access to three endpoints in its region. Verify connectivity on Windows and macOS and fix registration failures.
The Origin agent needs outbound access to three Origin-hosted endpoints over standard HTTPS on TCP port 443. Each agent connects only to the endpoints for the region it was installed into. Verify that all three are reachable before you deploy the agent. If the registration endpoint is unreachable, installation fails. If an endpoint is blocked later, the agent stops sending telemetry or stops updating.
## Required endpoints
| Endpoint | Port | Used during | Purpose |
| - | - | - | - |
| `registration.prod.originhq.com` | 443 | Installation | Endpoint registration. The installer exchanges the provisioning token for the agent's unique client certificate. |
| `endpoint.prod.originhq.com` | 443 | Ongoing operation | The agent's steady-state connection. Used for heartbeat, telemetry, policy and configuration, commands, and update checks. |
| `agent-cdn.prod.originhq.com` | 443 | Ongoing operation | Content delivery. Used to download agent updates and detection content, and to upload diagnostic log bundles requested by support. |
| Endpoint | Port | Used during | Purpose |
| - | - | - | - |
| `registration.aus.originhq.com` | 443 | Installation | Endpoint registration. The installer exchanges the provisioning token for the agent's unique client certificate. |
| `endpoint.aus.originhq.com` | 443 | Ongoing operation | The agent's steady-state connection. Used for heartbeat, telemetry, policy and configuration, commands, and update checks. |
| `agent-cdn.aus.originhq.com` | 443 | Ongoing operation | Content delivery. Used to download agent updates and detection content, and to upload diagnostic log bundles requested by support. |
**Web proxy or SASE gateway in the path?** We recommend allowing all three hostnames for your region on TCP 443 and **excluding them from TLS/SSL inspection**. The agent validates the certificate it receives, so a gateway that re-signs the connection can cause registration, updates, and heartbeat to fail even when the TCP port is open. We also recommend allowlisting the full hostnames rather than specific URLs, because download and upload links on the CDN are signed, short-lived, and different each time.
## Verifying connectivity
Run these checks on the target endpoint before installation. A successful TCP connection on port 443 is the main signal you're looking for. These endpoints serve the agent rather than a web page, so a browser that gets an HTTP error back is expected and doesn't mean the check failed.
The examples below use the United States hostnames. For Australia, replace `prod` with `aus` in each hostname.
Run the following in an elevated PowerShell session. The commands confirm that the endpoint can open a TCP connection to each Origin host on port 443.
```powershell theme={null}
Test-NetConnection registration.prod.originhq.com -Port 443
Test-NetConnection endpoint.prod.originhq.com -Port 443
Test-NetConnection agent-cdn.prod.originhq.com -Port 443
```
**Expected output:** For each command, `TcpTestSucceeded` should report `True`. A populated `RemoteAddress` also confirms that the hostname resolved in DNS.
To also confirm that the TLS handshake completes end to end, which is useful when a proxy sits in the path, run:
```powershell theme={null}
curl.exe -sv https://registration.prod.originhq.com 2>&1 | Select-String "Connected|SSL|TLS|certificate"
```
A clean handshake shows the connection being established and the TLS certificate being presented without error.
Run the following in Terminal. The `nc` commands test TCP reachability to each Origin host on port 443.
```bash theme={null}
nc -vz registration.prod.originhq.com 443
nc -vz endpoint.prod.originhq.com 443
nc -vz agent-cdn.prod.originhq.com 443
```
**Expected output:** Each command should report `Connection to ... port 443 [tcp/https] succeeded!`
To confirm that the TLS handshake completes, and to see whether a proxy is intercepting the connection, run:
```bash theme={null}
curl -sv https://registration.prod.originhq.com 2>&1 | grep -iE "connected|SSL|TLS|certificate"
```
If you suspect a DNS problem, first confirm that all three hostnames resolve, then test the TCP connection:
```bash theme={null}
dig +short registration.prod.originhq.com
dig +short endpoint.prod.originhq.com
dig +short agent-cdn.prod.originhq.com
```
## If connectivity is unavailable
Installation runs in two phases. The first phase copies files and registers the agent's service or daemon, and doesn't need network access. The second phase registers the agent with the backend through the registration endpoint for your region, and does need network access. If that endpoint is unreachable, the install fails.
### What the failure looks like
* **Windows:** The MSI's final registration step runs during `InstallFinalize`. If it can't reach the registration endpoint, it returns a non-zero result and the installer reports a failed installation. Under Intune, this shows up as a failed app installation.
* **macOS:** The `.pkg` postinstall script performs registration. If the endpoint is unreachable, the postinstall step fails and the package install reports failure.
In both cases the agent never receives its client certificate, so it can't authenticate to Origin even after connectivity is restored. Re-run the installer once the endpoint is reachable.
### If registration succeeds but an endpoint is blocked later
Sometimes the registration endpoint is reachable at install time, but the `endpoint` host for your region is blocked afterward, for example by a later firewall or proxy change. The agent stays installed and registered, but it can't send heartbeats, retrieve configuration, or report AI activity. In the Origin console, the endpoint shows a stale or missing **last seen** time and reports no telemetry. If the `agent-cdn` host for your region is blocked later, the agent keeps running but can't download updates or upload diagnostic logs.
To avoid these failure modes, use the checks above to confirm that all three endpoints for your region are reachable before you deploy the agent at scale.
# Origin Agent Prerequisites and Known Compatibility Issues
Source: https://docs.originhq.com/kb/prerequisites
Review network endpoints, VC++ requirements, and SASE and application control compatibility issues before deploying the Origin agent at scale.
Before you install the Origin agent, make sure each endpoint meets the requirements below and that your network and security policies do not silently interfere with agent operation. Addressing these prerequisites up front prevents the most common deployment failures.
## Visual C++ Redistributable
The Origin agent requires **Microsoft Visual C++ 2015–2022 Redistributable (x64) version 14.44** to be present on every Windows endpoint.
| Installer type | Visual C++ behavior |
| - | - |
| `.exe` | Silently installs the redistributable if it is not already present — no action needed |
| `.msi` | Requires the redistributable to be pre-installed, or linked as a prerequisite in your deployment tool before the MSI runs |
If you deploy via MDM or a software management platform using the MSI, ensure Microsoft Visual C++ 2015–2022 Redistributable (x64) is pushed to endpoints as a dependency before the Origin MSI executes. Failure to do so will cause the installer to exit with error `-1073741515`.
## Network Connectivity
The Origin agent must be able to reach the following two endpoints over outbound HTTPS (port 443) from every managed host. These connections are required both during initial installation and for ongoing operation.
| Endpoint | Purpose |
| - | - |
| `https://registration.prod.originhq.com` | Agent registration and credential exchange |
| `https://endpoint.prod.originhq.com` | Continuous telemetry and policy delivery |
If your environment enforces an explicit proxy or firewall allowlist, add both hostnames before deploying the agent. You can verify reachability from an endpoint at any time — see [Network Connectivity](/kb/network-connectivity) for platform-specific commands.
## SASE and TLS-inspection compatibility
Origin collects AI event data at the application layer — through each AI tool's OpenTelemetry exporter and through application-level hooks — so a SASE gateway sitting in front of your AI provider traffic does **not** affect capture. There is no need for a per-process or per-destination bypass rule for AI-bound flows.
What a gateway *can* break is the agent's own connection to Origin. Both `registration.prod.originhq.com` and `endpoint.prod.originhq.com` must be reachable on TCP 443 and **excluded from TLS/SSL inspection** — the agent validates the certificate it receives, so a gateway that re-signs the connection will cause registration and heartbeat to fail.
See [Network Connectivity](/kb/network-connectivity) for verification commands.
## OTLP collector port
The agent runs a local OpenTelemetry collector on the endpoint's loopback interface, on port **4318** by default.
If another process already owns that port — a corporate OTel collector such as Datadog, Alloy, or Dynatrace — that host will not capture AI telemetry until the conflict is cleared.
Either free the port or set a different **OTLP collector port** fleet-wide under **Endpoints → Configuration**. Check for a conflict before a large rollout. See [Console Setup](/getting-started/console-setup).
## Application Control (Windows)
Origin's Windows agent installs no kernel network driver, so there is nothing to exclude in Windows Defender Application Control (WDAC), AppLocker, or third-party equivalents.
# Send Feedback
Source: https://docs.originhq.com/kb/report-issues
Send a bug report or feature request to the Origin team from the Send Feedback form, with an optional affected endpoint, attachments, and agent logs.
Origin includes a built-in **Send Feedback** form that lets you send a bug report or feature request directly to the Origin team without leaving the platform. When you submit a report, Origin attaches the endpoint context you select and any files you upload, so the team has the information they need to reproduce the issue or scope the request — often without any follow-up.
## Opening Send Feedback
Send Feedback is reached from your avatar, not from Admin or Endpoints — it's personal to you, not tenant configuration. Click your avatar in the bottom-left corner of the console and select **Send Feedback**.
## Filling out the report form
Complete as many fields as you can. The more context you provide, the faster the team can act on your report.
| Field | What to enter |
| - | - |
| **Type** | **Bug** or **Feature** — switch this first, since it changes the submit button's label and what the description placeholder asks for. |
| **Title** | A short, one-line summary of the issue or request, for example *"Crash when opening endpoint details."* |
| **Description** | Everything else in one field: what you were doing, what happened, what you expected instead, and any steps, timing, or affected page that can help the team reproduce it. Screenshots or logs go in Attachments, not here. |
Even for a feature request, describe the workflow you were trying to complete in **Description** — it helps the team understand the use case and prioritize appropriately.
## Adding context and attachments
The right-hand rail of the Send Feedback form contains two optional but highly recommended sections.
**Affected endpoint** — Search for and attach a specific endpoint's agent logs and telemetry to the report. Leave this blank for a general product or dashboard issue that isn't tied to one machine.
**Attachments** — Drag and drop files, or click **Choose files** to upload up to 10 attachments. Most file types are accepted; executables are blocked. Each file can be up to 250 MB. Screenshots of error states, exported logs, and diagnostic reports are all good candidates.
## Submitting the report
Click **Send Bug Report** or **Send Feature Request** (the label tracks the **Type** you selected) to send the report to the Origin team. You do not need to follow up — the team will reach out if they need additional information.
For urgent production issues or situations where the built-in form is not accessible, contact Origin support directly. The support team can escalate and triage time-sensitive reports outside the normal queue.
***
## What to include for faster resolution
The details below aren't separate form fields — fold them into **Description** — but including them significantly reduces back-and-forth.
For agent-related issues, include the runtime logs from the affected endpoint.
**Windows**
1. Click the Origin icon in the **system tray**.
2. Select **Open Log Folder**.
3. The folder `C:\ProgramData\Origin\Agent\Logs\` opens in Explorer. Zip the contents and attach them to your report.
**macOS**
1. Click the Origin icon in the **menu bar**.
2. Select **Open Log Folder**.
3. The folder `/Library/Origin/logs/` opens in Finder. Compress the folder and attach it to your report.
For console or platform issues that are not agent-related, include a screenshot of the affected view and your browser console output (open browser DevTools → **Console** tab, reproduce the issue, then copy the output).
**Windows**
1. Click the Origin icon in the **system tray** to open the agent menu.
2. The agent version is displayed at the bottom of the menu.
Alternatively, open **Settings → Apps** (Windows 11) or **Control Panel → Programs and Features** (Windows 10), and look for **Origin Observability Agent** in the list.
**macOS**
1. Click the Origin icon in the **menu bar**.
2. The version string appears at the bottom of the dropdown menu.
Alternatively, run the following in Terminal:
```bash theme={null}
defaults read /Library/Origin/agent/Info.plist CFBundleShortVersionString
```
Include the full version string (for example, `1.4.2`) in your report.
If you are reporting a problem with the agent — such as missing AI events, a red or yellow tray icon, or an installation failure — attach the **Diagnostic Report** output to your ticket. To generate it: click the tray icon (Windows) or menu bar icon (macOS) → select **Run Diagnostics**. Copy or screenshot the full output, where every check should ideally read **OK**. Any failing line gives the team an immediate starting point.
# How to Fully Uninstall the Origin Agent from Windows
Source: https://docs.originhq.com/kb/windows-uninstall
Remove the Origin agent from Windows using msiexec, then manually delete the Origin data folder at C:\ProgramData\Origin to fully clean up the endpoint.
Uninstalling the Origin agent on Windows is a two-step process: first remove the agent using `msiexec.exe`, then manually delete the data folder that the uninstaller leaves behind.
## Step 1 — Remove the agent with msiexec
Run the following command in an elevated Command Prompt or PowerShell session, replacing `x.y.z` with the version number of the MSI used to install the agent. The installer filename follows the pattern `origin-installer--windows-x64.msi`.
```bat theme={null}
msiexec.exe /X origin-installer-x.y.z-windows-x64.msi /quiet /norestart
```
Wait for the command to complete before proceeding.
## Step 2 — Delete the Origin data folder
The uninstaller does not remove the Origin data directory. After the uninstall completes, delete the following folder manually to fully clean up the endpoint:
```text theme={null}
C:\ProgramData\Origin
```
You can delete this folder in File Explorer or using an elevated PowerShell session:
```powershell theme={null}
Remove-Item -Recurse -Force "C:\ProgramData\Origin"
```
After uninstalling, the endpoint will stop appearing as active in the Origin console. If you want to confirm removal immediately, check **Endpoints → Overview** — the endpoint's status will stop updating once the agent is no longer running.
# Windows: Origin Agent Fails with Error -1073741515
Source: https://docs.originhq.com/kb/windows-vc-error
Error -1073741515 (0xC0000135) means the Visual C++ Redistributable is missing. Install it before running the Origin agent installer on Windows.
When installing the Origin agent on Windows, you may see the installer exit with the following error:
```
Error: -1073741515 Undefined
```
This is the decimal form of `0xC0000135` (`STATUS_DLL_NOT_FOUND`). It means a required DLL — specifically one provided by the **Microsoft Visual C++ Redistributable** — is missing from the system. The Origin agent depends on the VC++ runtime, and if the redistributable is not present, the agent's binaries cannot load and the installation fails.
This error is most common on fresh OS images, minimal builds, and Windows Server Core installations where the VC++ runtime has not been included.
## Resolution
Install the latest Microsoft Visual C++ Redistributable **before** running the Origin agent installer.
Download the latest supported package directly from Microsoft:
* **Microsoft documentation:** [Latest supported Visual C++ Redistributable downloads](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist)
Direct download links for the Visual C++ 2015–2022 runtime:
| Architecture | Download |
| - | - |
| x64 | [vc\_redist.x64.exe](https://aka.ms/vs/17/release/vc_redist.x64.exe) |
| x86 | [vc\_redist.x86.exe](https://aka.ms/vs/17/release/vc_redist.x86.exe) |
| ARM64 | [vc\_redist.arm64.exe](https://aka.ms/vs/17/release/vc_redist.arm64.exe) |
Most Windows endpoints require the **x64** package. On ARM64 hardware (for example, Surface Pro X or Snapdragon-based devices), install the ARM64 package instead.
After the VC++ Redistributable installs successfully, re-run the Origin agent installer. Installation should complete normally.
## Fleet deployment — chain VC++ as a prerequisite
For broad deployments via Intune, SCCM/MECM, or any other endpoint management platform, **chain or bundle the Visual C++ Redistributable as a prerequisite** so it is installed before the Origin agent. Doing so prevents this failure from occurring on endpoints where the runtime is not already present.
When deploying through Intune, configure the VC++ Redistributable as a dependency of the Origin agent app so that it is automatically installed first on any endpoint that does not already have it.
# Claude Enterprise Integration via Anthropic Compliance API
Source: https://docs.originhq.com/product/claude-enterprise
Connect your Claude Enterprise account to Origin using the Anthropic Compliance API to pull claude.ai activity for endpoints without the Origin agent.
Origin connects to Claude Enterprise through Anthropic's Compliance API. It pulls your organization's Claude activity directly from Anthropic and lands it in the same context graph as everything Origin observes on the endpoint.
## What it adds
Origin's agent already captures Claude where it runs on an instrumented endpoint — including Claude Code, Claude Desktop, Cowork, and browser-based agents. The Compliance API covers the rest of the organization: `claude.ai` and Claude Desktop usage on endpoints that are not running the agent, plus organization-level activity such as sign-ins, admin actions, and configuration changes. Both feed the same record of AI work.
With the key in place, Origin pulls Claude chats and messages, the files, projects, and artifacts attached to them, and activity feed events. Each chat is attributed to the user who ran it and threaded into the same traces, analytics, and inventory as the rest of your AI activity, so Claude usage can be investigated alongside the endpoint record.
## How it works
The connector runs on its own once the key is saved. It reads Claude's activity feed about once a minute, picks up the chats that changed, and pulls their new messages. The first sync backfills roughly the last 30 days. There is nothing to export and no schedule to manage.
The key is read-only. Origin reads from your Claude organization and does not write to it or delete anything.
## Before you start
Make sure you have the following before beginning setup:
* A **Claude Enterprise plan** with the Compliance API available. The Compliance API is generally available on Claude Enterprise, except for Public Sector organizations.
* The **Primary Owner** of your Claude organization. Only the Primary Owner can enable the Compliance API and create access keys.
* An **Origin admin**, who can save the key in the Origin dashboard.
## Setup
The Primary Owner performs this step once for the organization.
1. Sign in to [claude.ai](https://claude.ai) as the Primary Owner.
2. Open **Organization settings → API** ([claude.ai/admin-settings/api-access](https://claude.ai/admin-settings/api-access)).
3. Under **Compliance API**, click **Enable**.
1. In claude.ai, go to **Settings → Data and Privacy → Compliance access keys**.
2. Click **Create key** and give it a name — for example, `Origin`.
3. Select these three scopes:
* `read:compliance_activities`
* `read:compliance_user_data`
* `read:compliance_org_data`
4. Click **Create** and copy the key immediately. It begins with `sk-ant-api01-`, and Claude shows it only once — store it somewhere safe before closing the dialog.
Origin uses all three scopes: **activities** to find what changed, **user data** to read chats and their files, and **org data** to attribute activity to the right people. Leave `delete:compliance_user_data` unselected — Origin does not use it.
Scopes are fixed once a key is created. If a required scope is missing, delete the key and create a new one with all three read scopes selected.
1. Sign in to the Origin dashboard at [dashboard.originhq.com](https://dashboard.originhq.com) as an admin.
2. Open **Settings → Integrations → Anthropic Compliance API key**.
3. Paste the key into the **Compliance Access Key** field.
4. Click **Save key**.
Origin stores the key encrypted and does not show it again. Once it is saved, the section reads **Configured** and reports the current sync status.
## What to expect after connecting
Origin begins pulling data within a few minutes of the key being saved. New Claude activity then flows continuously into your traces, analytics, and inventory alongside the endpoint record. No further setup is required.
## Changing or removing the connection
* **Rotate the key:** Create a new Compliance Access Key in claude.ai, then click **Replace key** in Origin and paste the new key.
* **Disconnect:** Click **Remove** in Origin. New activity stops syncing; data already in Origin is unaffected.
* **Revoke access:** Delete the key in claude.ai under **Settings → Data and Privacy → Compliance access keys**. This immediately stops all syncing.
## Troubleshooting
| Symptom | Likely cause | Resolution |
| - | - | - |
| Still reads "Not configured" after saving | The field was empty or the save did not complete | Paste the key again and click **Save key**. |
| Sync reports a 403 error | The Compliance API is not enabled, or the key is missing a scope | Confirm the Compliance API is enabled in claude.ai and the key holds all three read scopes. If a scope is missing, delete the key and create a new one. |
| No Claude activity appears | The key is valid but there is no recent Claude usage, or none within the backfill window | Use Claude, then wait for the next sync cycle. |
| Sync stops after previously working | The key was deleted or revoked in claude.ai | Create a new key in claude.ai and click **Replace key** in Origin. |
## What Origin accesses
Origin's access is intentionally narrow and read-only:
* **Read access** to your Claude organization through the three scopes listed above: chats, messages, files, projects, artifacts, and activity feed events.
* **No delete access**, and no ability to change anything in your Claude organization.
* The Compliance Access Key is **stored encrypted** in Origin and is never shown again after you save it.
# Data Sources
Source: https://docs.originhq.com/product/data-sources
Connect off-endpoint AI activity from Admin → Data Sources: add the Anthropic Compliance API key for claude.ai and enable Microsoft 365 Copilot capture.
**Data Sources** connects Origin to AI activity that happens off the endpoint — in the cloud, through a provider's own API — rather than through the Origin agent. Open it at **Admin → Data Sources** in the console.
Data Sources is tenant-wide configuration under **Admin**, alongside [Access](/getting-started/user-management) and [Identity](/product/identity-integration). It is not part of your personal [My Account](/getting-started/settings-view) settings.
## Anthropic Compliance API key
Lets Origin pull your organization's `claude.ai` and Claude Desktop chats through Anthropic's Compliance API, so they appear alongside your other captured prompts.
Paste a Compliance Access Key — it begins with `sk-ant-api01-` and is created in claude.ai under Compliance Access Keys. The key is stored encrypted and never shown again after saving. Until one is added the card reads **Not configured**; once saved it reads **Configured — connected** and offers **Remove** and **Replace key**.
For the full setup walkthrough, including the Claude-side steps and the scopes Origin needs, see [Claude Enterprise](/product/claude-enterprise).
## Microsoft 365 Copilot capture
Pulls Microsoft 365 Copilot prompts and responses (Word, Excel, Outlook, Teams, Copilot Chat) into AI activity, attributed to each person.
Copilot capture is enabled **per connected Microsoft Entra ID directory** — each appears as its own card — and needs no extra credentials beyond the directory integration's admin consent. A directory that hasn't finished connecting shows **Not connected** and cannot be enabled until you complete it under [Directory Integrations](/product/identity-integration).
Once connected, each card carries a **Capture Copilot activity** toggle, a delivery mode, and a **Readiness** section with a **Check readiness** / **Re-check** button that makes live Microsoft API calls.
Turning the toggle on is not sufficient on its own. Capture stays blocked until the Microsoft-side prerequisites pass, so run the readiness check after enabling.
For prerequisites, the APIs involved, and troubleshooting, see [Microsoft 365 Copilot](/getting-started/microsoft-365-copilot).
# Microsoft Entra ID Setup: Sync Users and Groups to Origin
Source: https://docs.originhq.com/product/entra-id-setup
Connect Microsoft Entra ID to Origin with automated setup in about two minutes, no app registration required, or use the manual advanced method.
Connect Origin to Microsoft Entra ID (formerly Azure AD) so your users, groups, group memberships, and devices stay in sync with your directory. Once connected, the synced data appears in the **Directory Browser** in your Origin dashboard, and each endpoint Origin sees is correlated to the person and device it belongs to.
There are two ways to connect Entra ID:
* **Automated setup (recommended)** — Origin manages the Entra application for you. There's no app registration to create, no Microsoft Graph permissions to add, and no client secret to generate or rotate. The whole flow takes about two minutes. This is the method below.
* **Manual setup (advanced)** — register and manage your own Entra app registration, Graph permissions, and client secret. Use this only if your organization requires full control over the app registration and credential rotation. See [Manual setup (advanced)](#manual-setup-advanced) further down this page.
***
## Automated setup
Origin now manages the Entra application for you. There is **no app registration to create, no Microsoft Graph permissions to add, and no client secret to generate or rotate**. You give one-time tenant-wide admin consent to Origin's verified application, choose what to sync, and you're done.
### What you'll end up with
| Synced from Microsoft Entra | Origin surface |
| - | - |
| Users | Directory Browser → **Users** tab |
| Groups (including nested groups) | Directory Browser → **Groups** tab |
| User → group memberships | Click a user → **Groups** panel |
| Entra-joined / registered devices | Directory Browser → **Devices** tab |
| Intune-managed devices (with serial numbers) | Directory Browser → **Devices** tab |
| Endpoint ↔ user correlation | Endpoint detail → **Assigned identity** |
The same admin consent also enables [**Microsoft 365 Copilot capture**](/getting-started/microsoft-365-copilot) — see that guide to turn it on once the directory is connected.
### Before you begin
You need:
1. **A Microsoft Entra admin who can grant tenant-wide admin consent** — the **Global Administrator**, **Privileged Role Administrator**, or **Cloud Application Administrator** role. This is the only Microsoft-side privilege the flow requires.
2. **An Origin admin account** — only Origin admins can create directory integrations.
You do **not** need:
* An app registration, a service principal, Graph API permissions, a redirect URI, or a client secret. Origin's managed application (published and verified as **Prelude Research Inc.**) handles all of that.
### Setup steps
1. Sign in to the Origin dashboard at [dashboard.originhq.com](https://dashboard.originhq.com/).
2. Click **Admin** in the left sidebar, then select **Identity**.
3. On the **Integrations** tab, click **Add Integration** (or the empty-state prompt if this is your first one).
The **New integration** dialog opens.
1. **Display name** — a label for this integration, e.g. `OriginHQ`. This is required and is only used to identify the integration in the list.
2. **Provider** — leave this set to **Microsoft Entra ID**. (Use **Change** if you need a different provider.)
3. Note the message: *"Origin manages the application registration and signing credentials — there's nothing to enter."*
4. Click **Connect Microsoft Entra**.
Origin saves the integration and opens Microsoft's admin-consent page in a new tab.
In the new tab:
1. **Pick an account** — choose (or sign in as) an account that holds one of the admin roles listed in *Before you begin*.
2. Microsoft shows a **Permissions requested — Review for your organization** screen for the **Prelude Research Inc.** application. The app requests read-only access to:
| Consent screen wording | What Origin uses it for |
| - | - |
| Sign in and read user profile | Completes the consent sign-in. |
| Read all users' full profiles | Populates the Users tab and user → group joins. |
| Read all groups | Enumerates groups, members, and nested-group edges. |
| Read all devices | Enumerates Entra-joined and Entra-registered devices. |
| Read Microsoft Intune devices | Brings in Intune-managed devices with hardware serial numbers for endpoint correlation. |
| Read organization information | Reads tenant-level directory details. |
| Read all audit log data | Supplies each user's last sign-in time for stale-account detection. |
| Read activity data for your organization | Usage/activity reporting across the tenant. |
| Read all AI enterprise interactions | Enables [**Microsoft 365 Copilot capture**](/getting-started/microsoft-365-copilot) (optional; you enable it separately). |
| ![The Microsoft admin-consent screen for the Prelude Research Inc. application, listing the requested read-only permissions.]()
| |
3. Click **Accept**. Consent applies to all users in your organization — no one else is prompted.
**If Accept is greyed out or you see a 'needs admin approval' message,** your account doesn't hold one of the roles in *Before you begin*. Have an eligible admin complete this step; everything else is already saved on Origin's side.
When you click **Accept**, return to the Origin tab. Origin automatically opens the **Sync scope** prompt so you can choose what to sync before the first sync runs.
As soon as consent completes, Origin opens the **Sync scope** dialog. Choose one of two modes, then click **Save** — Origin runs the first sync as soon as you save.
**Sync only selected groups**
* Leave **Sync full tenant** off, then use **Search groups by name** and tick the Entra groups you want. Only members of the selected groups — including members of nested groups — are monitored.
* Everyone outside the selected groups is left out, and anyone previously synced but no longer in scope is removed on the next sync.
**Sync the whole tenant**
* Turn on **Sync full tenant** to sync your entire directory. The group list is disabled and the dialog footer reads **Whole tenant**.
If you close this dialog without saving, the integration's scope stays **Not configured** and nothing syncs. You can reopen **Sync scope** from the integration row at any time (see the next step) and change your selection; the change takes effect on the next sync.
When the sync completes, Origin returns you to the **Directory Integrations → Integrations** tab. The integration row shows:
* **Status** — **Connected** (green).
* **Name** — the display name you entered.
* **Provider** — Microsoft Entra ID.
* **Scope** — **Whole tenant**, or the groups you selected.
* **Last Sync** — the time of the most recent sync.
To change what syncs later, click the **Scope** value on this row to reopen the **Sync scope** dialog; the change takes effect on the next sync.
From the Directory Integrations page, use the tabs across the top:
1. **Users** — should list everyone in scope. Click any user to see their direct groups; click a group to deep-link into it.
2. **Groups** — click any group to see its direct user members and sub-groups. Click a member to jump back to that user.
3. **Devices** — Intune-managed devices show a hardware serial number; Entra-joined devices that Intune hasn't seen show the device's display name. Both resolve an **Owner** against the synced users.
If you've registered endpoints in Origin and their serial numbers or hostnames match, those endpoints light up with the matched directory user under **Assigned identity**.
### What gets synced (and what doesn't)
**Synced:**
* Users (active and disabled) — display name, email, UPN, department, job title, manager, last sign-in, account-enabled flag.
* Groups — display name, description, type, membership, and nesting.
* Entra-joined / registered devices — display name, OS, OS version, owners.
* Intune-managed devices — serial number, model, manufacturer, assigned user, compliance state, OS.
**Not synced:**
* Mailboxes, OneDrive, calendars, contacts, or any tenant data outside the directory itself.
* Conditional Access policies or role assignments.
* Guest accounts (`#EXT#` UPN suffix) are filtered out at sync time.
### Managing the integration
* **Re-scope** — click the scope column and adjust **Sync scope** at any time.
* **Enable Copilot capture** — the admin consent you granted already covers it; turn it on in [**Microsoft 365 Copilot capture**](/getting-started/microsoft-365-copilot).
* **Remove** — delete the integration from its row's actions. Syncing stops; data already in Origin follows your tenant's retention settings. To also revoke access on the Microsoft side, remove the **Prelude Research Inc.** enterprise application from **Entra → Enterprise applications**.
### Troubleshooting
The signed-in account doesn't have permission to grant tenant-wide admin consent. Use an account with the **Global Administrator**, **Privileged Role Administrator**, or **Cloud Application Administrator** role.
The scope is probably still **Not configured** — the **Sync scope** dialog was closed without saving. Click the **Scope** value on the integration row to reopen it, choose **Sync full tenant** or select groups, and **Save**.
You're likely in **selected groups** mode. Open **Sync scope** and confirm the groups you expect are ticked — remember only members of the selected groups (and their nested groups) are synced.
Re-open the integration and confirm admin consent completed for the whole permission set. If consent was only partially granted, remove the integration and re-run the connect and consent steps with an eligible admin.
Your tenant may not use nested groups. In Entra, open a group → **Members** and look for entries whose **Type** is **Group**; if there are none, there's nothing for Origin to nest.
***
## Manual setup (advanced)
Prefer to manage your own Entra app registration, Microsoft Graph permissions, and client secret rotation directly, rather than using Origin's managed application? Use this method instead of the automated setup above.
This method walks through registering an application in your Microsoft Entra ID tenant, granting the permissions Origin needs, and connecting the integration from the Origin dashboard using your own client ID and client secret.
The whole flow takes about ten minutes and requires a Microsoft work account with the **Global Administrator**, **Privileged Role Administrator**, or **Cloud Application Administrator** role — anyone who can grant tenant-wide admin consent for an application.
### What you'll end up with (manual setup)
| Synced from Microsoft Entra | Origin Surface |
| - | - |
| Users (`/v1.0/users`) | Directory Browser → Users tab |
| Groups (`/v1.0/groups`) | Directory Browser → Groups tab |
| Direct user → group memberships | Click a user → "Groups" panel |
| Direct group → group nesting | Click a group → "Sub-groups" panel |
| Entra-joined / registered devices (`/v1.0/devices`) | Directory Browser → Devices tab |
| Intune-managed devices (`/v1.0/deviceManagement/managedDevices`) | Directory Browser → Devices tab (with serial numbers) |
| Endpoint ↔ user correlation by serial number or hostname | Endpoint detail panel "Assigned identity" |
Initial sync runs as soon as you finish the last step below. After that, Origin re-syncs every hour, plus an on-demand button in the dashboard.
### Before you begin (manual setup)
You need:
1. **An Entra admin account** with one of the roles listed above.
2. **The Origin dashboard URL** for your tenant — the public hostname you sign in to. The redirect URI you'll register in Entra is `https:///integrations/oauth-callback`. For example, if you sign in at `https://app.origin.example.com`, the redirect URI is `https://app.origin.example.com/integrations/oauth-callback`.
3. **Your Origin tenant admin role** — only Origin admins can create directory integrations.
You do **not** need a pre-configured service principal. The setup below creates one.
**Last sign-in time** (`last_login` in the Directory Browser) is sourced from Entra's `signInActivity` resource, which requires an **Entra ID P1 or P2** license plus the `AuditLog.Read.All` Graph permission. On the free tier — or on P1/P2 without `AuditLog.Read.All` granted — Graph silently omits the field and Origin records the user's last sign-in as the Unix epoch (`1970-01-01`). Stale-account detection that relies on this field will be best-effort until both prerequisites are in place. Everything else (users, groups, memberships, devices, owners) is available on the free tier with the permissions in the next step.
### Manual setup steps
Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) with your admin account, then:
1. Navigate to **Identity** → **Applications** → **App registrations** → **New registration**.
2. Fill in the registration form:
* **Name** — something a future admin will recognize, e.g. `Origin Directory Sync`.
* **Supported account types** — select *Accounts in this organizational directory only (Single tenant)*.
* **Redirect URI** — select **Web** and enter `https://dashboard.originhq.com/integrations/oauth-callback`. The hostname must match exactly (scheme, host, port, and path). Origin rejects callbacks whose redirect URI doesn't match what was stamped into the OAuth state.
3. Click **Register**.
You'll land on the new app's **Overview** page. Note down two values — you'll need them later:
* **Application (client) ID**
* **Directory (tenant) ID**
Keep the tab open.
Origin uses **application** permissions (also called *app-only* or *client\_credentials*), not delegated permissions, so the sync continues to run when no user is signed in.
1. In the same app registration, click **API permissions** → **Add a permission** → **Microsoft Graph** → **Application permissions**.
2. Add all six permissions in the table below. You can search by name; tick the checkbox and click **Add permissions** between groups if it's easier.
| Permission | Why Origin Needs It |
| - | - |
| `User.Read.All` | Enumerate users for the Directory Browser and the user → groups join. |
| `Group.Read.All` | Enumerate groups, group members, and nested-group edges. |
| `Directory.Read.All` | Stable cross-resource directory reads (covers `/v1.0/organization` and the delta endpoints). |
| `Device.Read.All` | Enumerate Entra-joined and Entra-registered devices via `/v1.0/devices`. |
| `DeviceManagementManagedDevices.Read.All` | Enumerate Intune-managed devices via `/v1.0/deviceManagement/managedDevices` — this is what brings hardware serial numbers in for endpoint correlation. |
| `User.Read` *(delegated, added by default)* | Sign-in completion when an admin grants consent. Already present after registration; leave it in place. |
3. After all six are listed, click **Grant admin consent for ``** at the top of the table. You'll be prompted to confirm — accept. Each row should now show a green check under **Status**.
If you see "Not granted for ``" with a yellow warning after clicking Grant, your account doesn't have one of the admin roles listed in the prerequisites. Either get the role assignment or hand this step to someone who has it — only the consent step is gated on it.
The previous step already added the redirect URI, but it's worth verifying — a typo here is the single most common reason the connect-to-Origin step fails.
1. Go to **Authentication** → under **Web** → **Redirect URIs**.
2. Confirm `https://dashboard.originhq.com/integrations/oauth-callback` is listed exactly as typed.
3. Leave everything else on this page at its default. Origin does not need the implicit grant flow, ID tokens, or any extra "Front-channel logout" URI.
4. Click **Save** if you changed anything.
The secret is what the Origin backend presents to Microsoft to acquire Graph tokens after admin consent completes. It's stored on Origin's side encrypted under your tenant's KMS-managed data key — Origin admins never see it in plaintext after entry.
1. Go to **Certificates & secrets** → **Client secrets** → **New client secret**.
2. **Description** — something descriptive, e.g. `origin-directory-sync-2026-q2`.
3. **Expires** — pick the longest window your security policy allows. Origin will warn you in the dashboard 14 days before the secret expires (the integration's status flips from **Connected** to **At risk**) so you can rotate before sync stops.
4. Click **Add**.
The secret value is shown **once** under the **Value** column. Copy it to your clipboard immediately — once you navigate away, the column shows only the last few characters and you'll need to create a new secret to recover. The **Secret ID** column is not the secret; you don't need it.
1. Sign in to your Origin dashboard at `https://dashboard.originhq.com/`.
2. Go to **Directory Integration** in the left sidebar → **+ Add Integration** (or click **Add your first integration** if this is the first one).
3. Select **Entra ID** (Microsoft Entra ID).
4. Fill in the connection form:
* **Display Name** — anything; this is just a label in the integrations list.
* **Tenant ID** — paste the Directory (tenant) ID from the app registration step.
* **Client ID** — paste the Application (client) ID from the app registration step.
* **Client Secret** — paste the **Value** you copied when creating the client secret.
5. Click **Connect with Entra ID**.
You'll be redirected to Microsoft to grant admin consent. Pick the admin account you used in the earlier steps (or sign in if prompted), review the permission list — it should match the six you added earlier — and click **Accept**.
When you land back at the Origin dashboard, the integration row shows status **Connected**. If it shows **No credentials stored for this integration** instead, the secret didn't make it through. Delete the row, return to the client secret step to create a fresh secret, and re-run this step.
Origin runs a periodic background sync, but you don't need to wait. Click **Sync** in the row's **Actions** column. The status flips to **Syncing**, then back to **Connected** with a populated **Last Sync** timestamp.
A typical first sync takes a few seconds for small tenants and a couple of minutes for tenants with tens of thousands of users.
If the sync turns the row red and shows an error, see the Troubleshooting section below.
1. Go to **Directory Integration** → **Directory Browser** tab.
2. The **Users** tab should list everyone Origin pulled.
3. Click any user. The detail panel shows their direct groups under a **Groups** subsection — click any group to deep-link into that group's detail.
4. Go to the **Groups** tab → click any group. The detail panel shows direct user members and direct sub-groups (if your tenant uses nested groups). Click any member to jump back to that user.
5. Check the **Devices** tab — Intune-managed devices show their serial number; Entra-joined devices that Intune hasn't seen show a blank serial and the device's `displayName`. Both share an **Owner** column resolved against synced users.
If you've registered endpoints in Origin and the device serial numbers match, you'll see those endpoint rows light up with the matched directory user under an **Assigned identity** column.
### What gets synced (manual setup)
**Synced — full list:**
* **Users** (active and disabled) — display name, email, UPN, department, job title, office, manager, last sign-in (best-effort — see *Before you begin (manual setup)*), account-enabled flag.
* **Groups** — display name, description, type (security / distribution / Microsoft 365), member count, direct memberships, direct sub-groups.
* **Entra-joined devices** — display name, OS, OS version, registered owners.
* **Intune-managed devices** — hardware serial number, model, manufacturer, assigned UPN, compliance state, OS, OS version.
**Not synced:**
* Photos, contacts, mailbox metadata, OneDrive, calendars, or any tenant data outside the directory itself.
* Conditional Access policies, role assignments, or audit logs.
* Service principals or managed identities.
* Personal-access guest accounts (`#EXT#` UPN suffix) — these are filtered out at sync time so they don't appear as "users" in the Directory Browser.
### Troubleshooting (manual setup)
Either the tenant ID, client ID, or redirect URI is wrong. Double-check that:
* The redirect URI in Entra exactly matches `https://dashboard.originhq.com/integrations/oauth-callback`.
* The tenant ID and client ID in the dashboard form match the **Directory (tenant) ID** and **Application (client) ID** on the app's **Overview** page — not the **Object ID**, which is a different value.
The client secret didn't reach Origin's backend. Most likely you left the **Client Secret** field blank, or pasted the **Secret ID** (the GUID in the right-hand column on Entra's secrets page) instead of the **Value**. Delete the integration in Origin, generate a fresh client secret in Entra, and reconnect.
The stored secret is rejected by Microsoft's token endpoint. Common causes:
* **The secret expired.** Check **Certificates & secrets** in Entra; if the **Expires** column is in the past, generate a new secret and use the integration's **Edit** action to update it.
* **The secret was revoked.** Same fix as above.
* **The application was deleted from Entra.** Re-register the application from the first step.
If only devices land and users/groups are empty, your app registration is probably missing the `User.Read.All` and `Group.Read.All` **application** permissions, or admin consent wasn't granted for them. Return to the Graph permissions step, confirm both rows have green checks under **Status**, and trigger the sync again.
Your tenant may not actually use nested groups — many small tenants don't. To confirm, navigate to one of your groups in Entra → **Members** and look for entries with the **Type** column set to **Group**. If there are none, there are no sub-groups for Origin to surface.
### Rotating the Client Secret
Origin shows a yellow **At risk** badge on the integration when the secret is within 14 days of expiry. To rotate without dropping sync:
1. Generate a new client secret in Entra. Don't delete the old one yet.
2. In the Origin dashboard, click **Edit** on the integration row, paste the new **Value** into the **Client Secret** field, and save.
3. Trigger a manual sync. If it succeeds, the new secret is live.
4. Delete the old secret from Entra.
### Removing the Integration
To stop syncing without revoking access in Entra:
1. Go to **Directory Integration** → click **Delete** in the row's **Actions** column. Origin tears down its end and tombstones the directory data (eligible for hard-delete after the retention window in your tenant settings, default 90 days).
2. Optionally revoke admin consent from your tenant: in Entra, go to **Identity** → **Applications** → **Enterprise applications** → pick your **Origin Directory Sync** app → **Permissions** → **Review permissions** → **This application has more permissions than I want it to have**. This revokes the granted permissions but leaves the app registration in place so you can re-grant later.
3. To fully remove the app, delete it from **App registrations** in Entra.
# Google Workspace Setup: Sync Users, Groups, and Devices
Source: https://docs.originhq.com/product/google-id-setup
Connect Google Workspace to Origin using a service account with domain-wide delegation to sync users, groups, organizational units, and devices.
Connect Origin to Google Workspace (Google ID) so your users, groups, group memberships, organizational units, and devices stay in sync with your directory. Once connected, the synced data appears in the **Directory Browser** in your Origin dashboard, and each endpoint Origin sees is correlated to the person and device it belongs to.
## How it works
Create a Google Cloud **service account**, grant it read-only access to your directory via **domain-wide delegation**, and paste three values — your **Customer ID**, an **Admin Email** to impersonate, and the service account's **JSON key** — into Origin. The whole flow takes about ten minutes and requires a Google Workspace **Super Admin** and a Google Cloud project you can administer.
### What you'll end up with
| Synced from Google Workspace | Origin surface |
| - | - |
| Users | Directory Browser → **Users** tab |
| Groups (including memberships) | Directory Browser → **Groups** tab |
| User → group memberships | Click a user → **Groups** panel |
| Organizational units | Directory Browser → user and group detail |
| Registered devices (via Cloud Identity) | Directory Browser → **Devices** tab |
| Endpoint ↔ user correlation | Endpoint detail → **Assigned identity** |
## Before you begin
You need:
1. **A Google Cloud project** you can administer — pick an existing one or create a new one for this integration.
2. **Google Workspace Super Admin access** — required to authorize domain-wide delegation and to look up your Customer ID.
3. **An Origin admin account** — only Origin admins can create directory integrations.
## Setup steps
1. In the [Google Cloud console](https://console.cloud.google.com), select or create the project you'll use for this integration.
2. Go to **APIs & Services → Library**.
3. Enable exactly two APIs: **Admin SDK API** and **Cloud Identity API**. Nothing else is needed.
Without the **Cloud Identity API**, users and groups still sync, but devices never do — and nothing reports an error when this API is missing.
1. In the same project, go to **IAM & Admin → Service Accounts** and create a new service account.
2. Open the new service account, go to **Keys → Add key → Create new key**, and choose **JSON**.
3. Save the downloaded file — you'll paste its entire contents into Origin's **Service Account JSON** field later.
It has to be a **service-account key**. An OAuth client-ID JSON downloaded from the Credentials page looks similar and is valid JSON, so it saves into Origin without complaint — and only fails later, when Origin asks Google for a token.
On the service account's **Details** tab, copy its **Unique ID** — the long number, not the service account's email address. This is the client ID the next step asks for.
1. Sign in to the [Workspace admin console](https://admin.google.com) as a Super Admin.
2. Go to **Security → Access and data control → API controls → Domain-wide delegation → Add new**.
3. Paste the service account's **Unique ID** into **Client ID**.
4. Paste all nine OAuth scopes below into **OAuth scopes**, then click **Authorize**.
```text theme={null}
https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly,https://www.googleapis.com/auth/admin.directory.orgunit.readonly,https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,https://www.googleapis.com/auth/admin.directory.domain.readonly,https://www.googleapis.com/auth/admin.directory.userschema.readonly,https://www.googleapis.com/auth/cloud-identity.devices.readonly,https://www.googleapis.com/auth/admin.reports.audit.readonly
```
| Scope | What it's for |
| - | - |
| `admin.directory.user.readonly` | People and their status |
| `admin.directory.group.readonly` | Groups |
| `admin.directory.group.member.readonly` | Group membership |
| `admin.directory.orgunit.readonly` | Organizational units |
| `admin.directory.rolemanagement.readonly` | Which accounts are super-admins or delegated admins |
| `admin.directory.domain.readonly` | Secondary domains, so people on them aren't counted as separate identities |
| `admin.directory.userschema.readonly` | Custom user attributes, such as employee ID or cost center |
| `cloud-identity.devices.readonly` | Registered devices, so a person can be attached to a machine |
| `admin.reports.audit.readonly` | The audit log, which is how Origin catches up without re-reading the whole directory |
Grant all nine scopes in one authorization. A partial grant is the hardest failure to diagnose — Google's error does not say which scope is missing. If Origin adds scopes in a future release, syncing stops until an admin re-authorizes the same client ID with the new list.
In the Workspace admin console, go to **Account → Account settings**. Your **Customer ID** starts with `C` (for example, `C0xxxxxxx`).
1. Sign in to the Origin dashboard at [dashboard.originhq.com](https://dashboard.originhq.com/).
2. Click **Admin** in the left sidebar, then select **Identity**.
3. On the **Integrations** tab, click **Add Integration**.
4. In the **New integration** dialog, fill in:
* **Display name** — a label for this integration, e.g. `Google Workspace`. Only used to identify it in the list.
* **Provider** — set to **Google Workspace**.
* **Customer ID** — the ID you copied in the previous step.
* **Admin Email** — the email address of the Super Admin the service account impersonates. Google requires delegation to impersonate a real administrator; because every granted scope is read-only, the service account can only read what that administrator could.
* **Service Account JSON** — paste the entire contents of the JSON key file you downloaded earlier.
5. Click **Create**.
Origin saves the integration and runs its first sync shortly after.
From the Directory Integrations page, use the tabs across the top:
1. **Users** — should list everyone in your Workspace directory. Click any user to see their direct groups.
2. **Groups** — click any group to see its direct members.
3. **Devices** — devices registered with Cloud Identity appear here, each resolved to an **Owner** against the synced users.
If you've registered endpoints in Origin and their serial numbers or hostnames match, those endpoints light up with the matched directory user under **Assigned identity**.
## What gets synced (and what doesn't)
**Synced:**
* Users — display name, email, status, organizational unit, and custom schema attributes covered by the granted scope.
* Groups — display name, description, and membership.
* Organizational units.
* Devices registered with Cloud Identity.
**Not synced:**
* Gmail, Drive, Calendar, or any Workspace application data outside the directory itself.
* Role and permission assignments beyond identifying which accounts are super-admins or delegated admins.
## Troubleshooting
**Display name**, **Customer ID**, **Admin Email**, and **Service Account JSON** are all required — Origin won't submit the form until every field has a value.
Confirm the file pasted into **Service Account JSON** is a service-account key — downloaded from **Keys → Add key** on the service account — and not an OAuth client-ID JSON from the Credentials page. Both are valid JSON, so Origin accepts either at save time, and only a service-account key succeeds when Origin requests a token from Google.
Confirm the **Cloud Identity API** is enabled for the Google Cloud project the service account belongs to. Without it, device sync fails silently — nothing in the UI reports the missing API.
One or more of the nine OAuth scopes is likely missing from the domain-wide delegation authorization. Google's error does not name the missing scope, so reopen the domain-wide delegation entry for this client ID in the Workspace admin console and confirm the full scope list matches exactly what's listed above.
The service account can only read what the impersonated **Admin Email** account could read itself. Use a full Super Admin account, not a delegated admin with a narrower role.
## Removing the integration
1. In **Directory Integrations**, delete the integration from its row's actions. Syncing stops immediately; data already in Origin follows your tenant's retention settings.
2. To also revoke access on the Google side, remove the domain-wide delegation entry for the service account's client ID from **Security → Access and data control → API controls → Domain-wide delegation** in the Workspace admin console, and optionally delete the service account and its key in Google Cloud.
# Connect an Identity Provider to Origin for Directory Sync
Source: https://docs.originhq.com/product/identity-integration
Sync users, groups, group memberships, and device-to-user assignments from your identity provider into Origin's Directory Browser for richer context.
Connect Origin to your identity provider so that users, groups, group memberships, and device-to-user assignments stay in sync with your source of truth. Once an integration is connected, the synced data appears in the **Directory Browser** in your Origin dashboard, giving every investigator richer context when reviewing endpoint activity.
## What Directory Integration Does
After you connect a provider, Origin periodically pulls directory data and surfaces it throughout the console:
* **Users** — every account in your directory, including display name, email, department, job title, and last sign-in time.
* **Groups** — security groups, distribution lists, and Microsoft 365 groups, with direct memberships and nested sub-groups.
* **Device-to-user assignments** — hardware serial numbers and assigned owners from your MDM or device management platform, used to correlate observed endpoints with real identities.
All of this data is browsable in the **Directory Browser**, and where serial numbers match endpoints already registered in Origin, you'll see an **Assigned identity** appear directly on the endpoint detail panel.
## Supported Providers
| Provider | Status | Notes |
| - | - | - |
| **Microsoft Entra ID** | Available | Automated setup connects in about two minutes — no app registration required. A manual, self-managed method is also available. |
| **Okta** | Available | Connect a read-only API Services app with public-key authentication — no client secret to store or rotate. |
| **Google ID** | Available | Requires creating a Google Cloud service account and authorizing it for domain-wide delegation — there is no app-consent flow Origin can drive for you. |
Grant tenant-wide admin consent to Origin's managed application and choose what to sync — no app registration required. A manual setup method is also available for advanced tenants.
Create a read-only Okta API Services app with public-key authentication — no client secret to store or rotate.
Create a Google Cloud service account with domain-wide delegation to sync users, groups, organizational units, and devices from Google Workspace.
# Origin MCP Server: Query Observability Data from AI Tools
Source: https://docs.originhq.com/product/mcp-server
Connect Claude, Claude Code, Cursor, Cline, or any remote-capable MCP client to Origin's MCP server and query endpoint and agent observability data.
Origin's Model Context Protocol (MCP) server lets you query your endpoint and agent observability data from any MCP client that supports remote servers — Claude (desktop and web), Claude Code, Cursor, Cline, and others. Ask natural-language questions about your AI agent activity, prompt usage, model spend, and endpoint behavior, and the LLM you're using translates them into structured queries against your Origin tenant.
This page covers what the server does, how to connect, sample prompts, common errors, and how to get support.
## What the MCP server gives you
Origin's MCP exposes read-only access to your analytics graph — the same data that powers the Origin console. From an MCP client you can answer questions like:
* Which agents are running on which endpoints, and what models are they calling?
* How much are we spending on each model, broken down by department or team?
* What prompts fail most often, and where?
* Which sessions had the longest tool-call chains yesterday?
The server is read-only. It cannot modify endpoints, agents, alerts, or any other Origin state.
## Connect a client
The server is a remote MCP server. It speaks Streamable HTTP and uses OAuth 2.1 with Dynamic Client Registration, so any MCP client that supports remote HTTP servers with OAuth can connect.
| | |
| - | - |
| **Server URL** | `https://mcp.prod.originhq.com/mcp` |
| **Transport** | Streamable HTTP |
| **Authentication** | OAuth 2.1 via your Origin login (WorkOS AuthKit) |
The first time you connect, your client opens a browser window so you can sign in to Origin. After that, your client refreshes tokens automatically.
You do not need to provision API keys, copy bearer tokens, or paste anything from the Origin console. The OAuth flow handles everything.
In the Claude apps, remote MCP servers are added as **custom connectors**. Custom connectors are available on Pro, Max, Team, and Enterprise plans.
Do not add Origin to `claude_desktop_config.json`. That file only supports local servers that Claude launches with a `command`. A `url` entry there will not connect, and depending on your Claude version it can stop the app from loading your other MCP servers.
**Pro and Max plans**
1. Open **Settings → Connectors**.
2. Click **Add custom connector**.
3. Enter a name (for example, `Origin`) and the server URL: `https://mcp.prod.originhq.com/mcp`. Leave the **Advanced settings** OAuth fields blank.
4. Click **Add**, then click **Connect** and sign in with your Origin account in the browser window that opens.
**Team and Enterprise plans**
1. A Claude organization **Owner** adds the connector once in **Organization settings → Connectors → Add custom connector**, using the URL above.
2. Each member then opens **Settings → Connectors**, finds Origin in the list, clicks **Connect**, and signs in with their own Origin account.
Once connected, enable Origin from the **+** (tools) menu in a chat if it isn't already on, then ask a question.
Custom connectors connect from Anthropic's cloud, not from your machine. This works with Origin's production server, which is publicly reachable.
Add the server with the CLI:
```bash theme={null}
claude mcp add --transport http origin https://mcp.prod.originhq.com/mcp
```
By default this adds the server for the current project only. Add `--scope user` to make it available in every project.
Then start `claude`, run `/mcp`, select **origin**, and choose **Authenticate** to sign in with your Origin account in the browser.
Add Origin to `~/.cursor/mcp.json` (all projects) or `.cursor/mcp.json` in a project root (that project only):
```json theme={null}
{
"mcpServers": {
"origin": {
"url": "https://mcp.prod.originhq.com/mcp"
}
}
}
```
Do not add an `auth` block or headers. Cursor registers itself with Origin automatically and prompts you to sign in.
Open the MCP section of Cursor's settings, confirm **origin** appears and is enabled, and click **Connect** or **Login** if Cursor shows that it needs authentication.
1. In the Cline panel, click the **MCP Servers** icon and open the **Remote Servers** tab.
2. Enter a server name (for example, `origin`) and the server URL: `https://mcp.prod.originhq.com/mcp`.
3. Set **Transport Type** to **Streamable HTTP**.
4. Click **Add Server**, then complete the sign-in prompt.
If you edit Cline's MCP settings file directly, set `type` explicitly. Without it, Cline uses the legacy SSE transport, which Origin does not support.
```json theme={null}
{
"mcpServers": {
"origin": {
"type": "streamableHttp",
"url": "https://mcp.prod.originhq.com/mcp"
}
}
}
```
Any client that supports remote MCP servers over Streamable HTTP with OAuth can connect. Point it at `https://mcp.prod.originhq.com/mcp`, choose the Streamable HTTP (sometimes labeled "HTTP") transport rather than SSE, and follow your client's instructions for OAuth sign-in.
If your client only supports local (stdio) servers, it cannot connect to Origin directly.
## Tools exposed
Your client discovers these tools automatically once connected. You don't call them yourself; the LLM picks the right one based on your question.
### Schema and query tools
The LLM typically uses these in order: read the map, pull details for the entities it needs, check the query grammar, then run the query.
| Tool | What it does |
| - | - |
| `analytics_describe_schema` | Returns a compact map of the analytics graph: entities, how they join, and which data domains exist. With no arguments it returns the **core** domain (endpoints, tokens, inventory, identity). Pass `domains` with one of `conversation`, `os_telemetry`, or `legacy` to see that domain's map. Field lists and examples are not included. |
| `analytics_describe_entities` | Takes a list of entity names from the schema map (for example `["ENDPOINT", "TOKEN"]`) and returns their fields, metrics, and worked query examples. |
| `analytics_query_guide` | Returns the query grammar and common pitfalls. Takes no arguments. |
| `analytics_query` | Runs a structured query against your tenant's data and returns columns, rows, a `truncated` flag, and cost details. |
`analytics_query` parameters (the LLM fills these in for you):
| Parameter | Purpose |
| - | - |
| `entity` | **Required.** The root entity, using names from the schema map (for example `ENDPOINT`, `TOKEN`, `AGENT_INVENTORY`) |
| `user_intent` | **Required.** A short summary of what you're trying to find out, recorded with the query |
| `alias` | Reference name for the root entity within the query |
| `joins` | How to traverse into related entities |
| `filters` | Predicates applied before aggregation |
| `select` | Dimension fields to return (optionally bucketed by time) |
| `metrics` | Aggregations to compute (counts, sums, averages, percentiles) |
| `order_by`, `limit`, `offset` | Sort and paging. `limit` defaults to 500 |
| `time_range_days` | Defaults to 30. Capped at each entity's data retention |
| `sample` | Distribution-preserving sampling for broad questions. Can't be combined with `metrics` or `offset` |
Queries that exceed your tenant's cost budget are rejected with a suggestion to narrow the scope.
### Conversation tools
| Tool | What it does |
| - | - |
| `analytics_read_conversation_record` | Reads a page of messages from one agent conversation, using a trace ID returned by `analytics_query`. |
| `analytics_read_conversation_content` | Reads specific pieces of a conversation in full, such as one message part, tool call arguments, or tool results. |
### Prior work search
| Tool | What it does |
| - | - |
| `search_prior_work` | Finds how similar work was previously requested and handled in your tenant's agent activity, so the LLM can build on it. |
## Sample prompts
Once connected, you can ask questions in plain English. Examples to try:
* "What models are my Claude Code agents calling this week, and on which endpoints?"
* "Show me total token spend by department over the last 30 days, sorted highest first."
* "Which prompts are failing most often? Group by model and tool name."
* "Find the ten longest agent sessions yesterday and show me which tools each one called."
* "Compare prompt latency p50 and p95 across our models for the past two weeks."
* "Which endpoints had AI activity for the first time this week?"
* "How many Claude Code sessions did each engineer run this week?"
* "Show me MCP server connections by endpoint — which agents are connecting to which servers?"
For the best results, give the LLM enough specificity to compose a query: include a time range, a grouping dimension, and what you want to measure. If the LLM asks clarifying questions, answer them — it's usually trying to disambiguate between similar fields.
## Troubleshooting
First, check how you added it:
* **Claude desktop or web:** Origin must be added under **Settings → Connectors**, not in `claude_desktop_config.json`. If you added a `url` entry to that file, remove it, fully quit and reopen Claude, and add Origin as a custom connector instead.
* **Cline:** Make sure the transport is **Streamable HTTP** (`"type": "streamableHttp"`), not SSE.
* **All clients:** Confirm the URL is exactly `https://mcp.prod.originhq.com/mcp` and that you completed sign-in.
If it still doesn't work, fully quit and reopen the client and check its MCP logs for connection errors.
Your client needs to support OAuth for remote MCP servers. Make sure you're on a recent version and update if needed. In Claude Code, run `/mcp`, select **origin**, and choose **Authenticate** to restart the sign-in flow.
On Team and Enterprise plans, only organization Owners can add custom connectors. Ask an Owner to add Origin in **Organization settings → Connectors**. Members can then connect from **Settings → Connectors**. Custom connectors aren't available on the Free plan.
Your token may have expired and your client may not be refreshing it. Disconnect and reconnect the server in your client's settings. If the problem persists, your Origin account may not have access to the tenant you're trying to query — confirm in the Origin console that you can see the data there first.
The LLM composed a query the server couldn't validate — usually a field referenced on the wrong entity, or a filter value of the wrong type. These come back as visible errors so the LLM can self-correct on the next turn. If it loops, ask the LLM to call `analytics_describe_entities` for the entities it's querying and `analytics_query_guide` before retrying.
You asked for something that would scan more rows than your tenant's per-query budget allows. The error message includes a suggestion — usually: narrow the time range, add a filter, or sample the result. Time-bound your question more tightly and try again.
The LLM may have applied a filter that doesn't match anything. Ask it to show the query it ran and check the filters. Common culprits: a hostname filter with the wrong case, or a time range that excludes the data you care about. Some entities keep data for a limited time, so very old data may no longer be available.
Analytics queries scale with the data they scan. If a question consistently takes more than 10–20 seconds, try narrowing the time range or asking for an aggregate (counts, top-N) instead of raw rows.
## Versioning and protocol
| | |
| - | - |
| **MCP protocol version** | `2025-06-18` (with fallback to `2025-03-26` and `2024-11-05`) |
| **Transport** | Streamable HTTP (POST `/mcp`) |
| **Auth** | OAuth 2.1 with Dynamic Client Registration (RFC 7591) and Protected Resource Metadata (RFC 9728) |
| **Request body limit** | 256 KiB |
Discovery metadata is published at `https://mcp.prod.originhq.com/.well-known/oauth-protected-resource` for clients that need it. You should not need to configure this manually.
## Data, privacy, and audit
Every tool call is recorded to Origin's audit log with the calling user, the tool name, a hash and snapshot of the arguments, the row count, bytes scanned, elapsed time, and outcome. Audit records are scoped per tenant and retained for 30 days.
Queries run with your user identity — you can only see what your Origin role allows you to see in the console. See [Access Control](/product/role-based-access-control).
## Get support
* **In-app:** Open the support panel in the Origin console.
* **Email:** [support@originhq.com](mailto:support@originhq.com)
When reporting an issue, include your MCP client and version, the prompt you ran, and any error message the client returned. If the server returned a structured error, the message is usually enough to pinpoint the problem.
# Okta Setup: Sync Users and Groups to Origin
Source: https://docs.originhq.com/product/okta-setup
Connect Okta to Origin using a read-only API Services app with public-key authentication — no client secret to store or rotate.
Connect Origin to Okta so your users, groups, group memberships, and devices stay in sync with your directory. Once connected, the synced data appears in the **Directory Browser** in your Origin dashboard, and each endpoint Origin sees is correlated to the person and device it belongs to.
Origin authenticates to Okta as an **API Services app** using **public key / private key** client authentication (OAuth 2.0 client credentials with a JWKS URL) — not a stored client secret or API token. Origin signs in with its own key, so there's no secret sitting in Okta or in Origin's database to leak or rotate.
## What you'll end up with
| Synced from Okta | Origin surface |
| - | - |
| Users | Directory Browser → **Users** tab |
| Groups (including nested groups) | Directory Browser → **Groups** tab |
| User → group memberships | Click a user → **Groups** panel |
| Registered devices | Directory Browser → **Devices** tab |
| Endpoint ↔ user correlation | Endpoint detail → **Assigned identity** |
## Before you begin
You need:
1. **An Okta admin who can create app integrations and assign admin roles** — someone who can create an **API Services** app under **Applications** and grant it the **Read-only Administrator** role.
2. **An Origin admin account** — only Origin admins can create directory integrations.
3. Your **Okta domain** — the host you sign in to (for example `yourorg.okta.com`). European (`.okta-emea.com`) and preview (`.oktapreview.com`) orgs are also accepted.
You do **not** need to generate or store a client secret. Origin's public key is published and Okta fetches it directly — see the setup steps below.
## Setup steps
1. Sign in to the Origin dashboard.
2. Click **Admin** in the left sidebar, then select **Identity**.
3. Click **Add Integration**.
4. In the **New integration** dialog:
* **Display name** — a label for this integration, e.g. `Okta`.
* **Provider** — set to **Okta** (use **Change** if it isn't already selected).
* **Okta domain** — enter your Okta host, e.g. `yourorg.okta.com`.
5. Click **Continue**.
![The Origin New integration dialog with Okta selected as the provider and an Okta domain entered, before clicking Continue.]()
Origin generates a unique app name and key URL for this integration and shows the steps to finish setup in Okta.
Origin now shows a **Finish setting up in Okta** panel with the exact values to use. Keep this panel open — you'll come back to it after saving the app in Okta.
1. In your Okta domain, go to **Applications → Create App Integration → API Services**.
2. **Name it exactly** the app name Origin generated (e.g. `origin-0ed37d524d3a`). Connecting reads the name back to confirm you own the org, so it must match character for character. Click **Copy** next to **App Name** in Origin to avoid typos.
![Origin's Finish setting up in Okta panel: the generated App Name, the Public Key URL and DPoP note, the 4 required scopes with the Read-only Administrator role requirement, and the Client ID field with the Connect button.]()
The app name is unique to this integration attempt. If you restart the **Add Integration** flow, Origin generates a new name — always copy the current one from the dialog rather than reusing a name from a screenshot or previous attempt.
Still on the new app in Okta:
1. Under **Client Credentials**, click **Edit**.
2. Set **Client authentication** to **Public key / Private key**.
3. Choose **Use a URL to fetch keys dynamically** and paste the **Public Key URL** Origin gave you:
```text theme={null}
https://api.prod.originhq.com/.well-known/okta-jwks.json
```
4. Leave **Require Demonstrating Proof of Possession (DPoP) header in token requests** **off**. Okta rejects the token request outright if it's on.
This is what lets Origin authenticate without a shared secret — Okta fetches Origin's current public key from that URL on each token request and verifies Origin's signed assertion against it.
1. Grant the app all four scopes below (all read-only):
| Scope | What it's for |
| - | - |
| `okta.users.read` | People and their status |
| `okta.groups.read` | Groups and membership |
| `okta.devices.read` | Registered devices |
| `okta.apps.read` | Reads this app's own name, to prove you own the org |
2. Assign the app the **Read-only Administrator** role. Granting the scopes above is necessary but not sufficient on its own — without the admin role, the same credential 403s on some endpoints and returns an empty list on others.
3. In **Application notes for admins**, add a note that this app is Origin's directory integration and that deleting it stops directory syncing. Origin holds only read-only scopes and can't add this note itself — without it, the app is easy to mistake later for something unused.
4. Save the app.
1. Okta shows the app's **Client ID** on its **General** tab once you save it. Copy it.
2. Back in Origin's **New integration** dialog, paste it into the **Client ID** field.
3. Click **Connect**.
Origin verifies the app name and credentials, then starts the first sync.
From **Admin → Identity**, the integration row should show **Status: Connected**, with **Provider: Okta** and a recent **Last Sync** time.
Then check the **Directory Browser**:
1. **Users** — should list everyone in your Okta org. Click any user to see their direct groups.
2. **Groups** — click any group to see its direct user members and sub-groups.
3. **Devices** — registered devices resolve an **Owner** against the synced users.
If you've registered endpoints in Origin and their serial numbers or hostnames match, those endpoints light up with the matched directory user under **Assigned identity**.
## What gets synced (and what doesn't)
**Synced:**
* Users (active and suspended) — profile fields, status, group memberships.
* Groups — name, description, membership, and nesting.
* Devices registered in Okta — device name, platform, and assigned user.
**Not synced:**
* Okta applications, sign-on policies, or authentication policies.
* MFA factors or credentials.
* Any Okta System Log / audit data.
## Managing the integration
* **Rotate:** Origin's authentication key is managed on Origin's side and rotates automatically — there's no customer-side secret to rotate. If you need to re-establish trust (for example, after editing the Okta app), re-open **Add Integration** to regenerate the app name and Client ID pairing.
* **Remove:** Delete the integration from its row in **Admin → Identity**. Syncing stops; data already in Origin follows your tenant's retention settings. To fully revoke access on the Okta side, delete the API Services app from **Applications** in Okta.
## Troubleshooting
The app name in Okta doesn't exactly match the name Origin generated. Reopen the integration's setup panel in Origin, copy the **App Name** again, and rename the Okta app to match it character for character (including the `origin-` prefix and casing).
Confirm **Require Demonstrating Proof of Possession (DPoP) header in token requests** is **off** — Okta rejects the token request outright with it on. Also confirm the **Public Key URL** was entered exactly as `https://api.prod.originhq.com/.well-known/okta-jwks.json`, with no trailing characters.
The app is missing the **Read-only Administrator** role. The four `okta.*.read` scopes alone aren't sufficient — assign the role in the app's **Admin roles** tab in Okta, then trigger a sync again.
Okta only shows the Client ID on the app's **General** tab after you save it. If you closed the app before saving, reopen it from **Applications** in Okta — the Client ID is stable and doesn't change on subsequent visits.
# OpenAI Compliance API Integration for ChatGPT and Codex
Source: https://docs.originhq.com/product/openai-compliance-logs
Connect your OpenAI workspace to Origin through the Enterprise Compliance Logs Platform to pull ChatGPT, app/MCP, and Codex activity. Available in preview.
**Preview.** The OpenAI Compliance Logs integration is available in preview. Contact your Origin Technical Account Manager for assistance enabling and configuring this integration for your tenant.
Origin connects to OpenAI through the Enterprise Compliance Logs Platform. It pulls your workspace's ChatGPT conversations, app/MCP calls, and Codex sessions directly from OpenAI and lands them in the same context graph as everything Origin observes on the endpoint.
## What it adds
Origin's agent already captures OpenAI activity where it runs on an instrumented endpoint — including the Codex CLI and ChatGPT Desktop (Chat, Work, and Codex surfaces). The Compliance Logs Platform covers the rest of the organization: ChatGPT conversations and app/MCP calls on endpoints that are not running the agent, plus Codex sessions run outside the endpoint. Both feed the same record of AI work.
With the key in place, Origin pulls ChatGPT conversations, app and MCP calls, and Codex sessions. Each is attributed to the workspace member who ran it and threaded into the same traces, analytics, and inventory as the rest of your AI activity, so ChatGPT usage can be investigated alongside the endpoint record.
## Before you start
Make sure you have the following before beginning setup:
* Access to the **OpenAI Enterprise Compliance Logs Platform** — either a ChatGPT workspace or an API-Platform organization with Compliance Logs enabled.
* Access to the **OpenAI admin console**, to locate your workspace or organization ID and create a Compliance Logs Platform key.
* An **Origin admin**, who can save the key in the Origin dashboard.
* Your **Origin Technical Account Manager** — reach out to them before starting. This integration is in preview, and they can confirm it's enabled for your tenant and help walk through setup.
## Setup
1. Sign in to the OpenAI admin console.
2. Locate your ChatGPT **workspace ID**, or, for an API-Platform organization, the `org-...` ID.
1. In the OpenAI admin console, create a **Compliance Logs Platform key** scoped to that workspace or organization.
2. Copy the key immediately — OpenAI shows it only once, so store it somewhere safe before closing the dialog.
1. Sign in to the Origin dashboard as an admin.
2. Open **Admin → Data Sources → OpenAI Compliance Logs key**.
3. Paste your **Workspace or organization ID** and **Compliance Logs Platform key** into the corresponding fields.
4. Click **Save Key**.
Origin stores the key encrypted and does not show it again. Once it is saved, the section reports the current sync status.
## What to expect after connecting
Origin begins pulling data shortly after the key is saved. New ChatGPT, app/MCP, and Codex activity then flows continuously into your traces, analytics, and inventory alongside the endpoint record. No further setup is required.
## Changing or removing the connection
* **Rotate the key:** Create a new Compliance Logs Platform key in the OpenAI admin console, then replace the key in Origin.
* **Disconnect:** Remove the key in Origin. New activity stops syncing; data already in Origin is unaffected.
* **Revoke access:** Delete the key in the OpenAI admin console. This immediately stops all syncing.
## Troubleshooting
| Symptom | Likely cause | Resolution |
| - | - | - |
| Still reads "Not configured" after saving | The workspace/organization ID or key field was empty, or the save did not complete | Re-enter both fields and click **Save Key**. |
| No ChatGPT or Codex activity appears | The key is valid but there's no recent activity in the configured workspace, or the workspace/organization ID doesn't match the key | Confirm the ID matches the workspace the key was created for, then use ChatGPT or Codex and wait for the next sync cycle. |
| Sync stops after previously working | The key was deleted or rotated in the OpenAI admin console | Create a new key in the OpenAI admin console and replace it in Origin. |
## What Origin accesses
Origin's access is intentionally narrow and read-only:
* **Read access** to the workspace or organization you configure: ChatGPT conversations, app/MCP calls, and Codex sessions.
* **No delete access**, and no ability to change anything in your OpenAI workspace or organization.
* The Compliance Logs Platform key is **stored encrypted** in Origin and is never shown again after you save it.
This integration is in preview. Behavior, field names, and setup steps may change — contact your Origin Technical Account Manager for the latest guidance and to confirm availability for your tenant.
# Perplexity API Integration
Source: https://docs.originhq.com/product/perplexity-integration
Capture Perplexity activity in Origin through Perplexity's Enterprise audit log webhook. Coming soon.
**Coming soon.** The Perplexity webhook integration is not yet available. This page describes the planned setup so you can confirm your Perplexity plan and seat count ahead of time.
Origin connects to Perplexity through Perplexity's Enterprise audit log webhook. Once configured in both Origin and your Perplexity organization, Perplexity pushes activity events to Origin directly, and Origin lands them in the same context graph as everything else it observes.
## What it adds
Perplexity activity pushed by the audit log webhook is attributed to the user who ran it and threaded into the same traces, analytics, and inventory as the rest of your AI activity, so Perplexity usage can be investigated alongside everything else Origin captures.
## How it works
The Perplexity webhook is push-based, not pull-based: Origin issues a unique webhook URL and bearer token for your tenant, and Perplexity uses them to send audit log events to Origin as they happen. There is nothing to export and no schedule to manage on the Origin side.
## Minimum Perplexity plan required
Perplexity's audit log webhook is an Enterprise-tier feature, and it is gated by plan and seat count on Perplexity's side:
| Requirement | Detail |
| - | - |
| **Plan** | Perplexity **Enterprise** (Pro or Max) |
| **Seats** | **50+ seats** on Enterprise Pro, **or** at least **one Enterprise Max seat** (Enterprise Max has no seat minimum) |
If your organization has fewer than 50 Enterprise Pro seats, you'll need to upgrade at least one seat to Enterprise Max before Perplexity will expose audit log webhook configuration to your org admins.
## Before you start
Make sure you have the following before beginning setup:
* A **Perplexity Enterprise organization** that meets the plan and seat requirements above.
* A **Perplexity org admin**, who can configure the webhook in Perplexity's organization settings.
* An **Origin tenant admin**, who can generate the webhook URL and bearer token in the Origin console.
## Setup
1. Sign in to the Origin console as an admin.
2. Open **Admin → Data Sources**.
3. Find **Perplexity** in the list of data sources.
4. Copy the **webhook URL**.
5. Click **Rotate Token** to generate a bearer token.
6. Copy the token right away and store it somewhere safe — Origin shows it only once, so take a screenshot or otherwise save both values before leaving the page.
Clicking **Rotate Token** again later replaces the token immediately. Any integration still using the old token will stop authenticating, so only rotate it when you're ready to update Perplexity with the new value.
![The Origin console's Admin → Data Sources page, showing the Perplexity Enterprise Audit Logs integration with its Webhook URL field and Rotate Token button.]()
1. Sign in to [perplexity.ai](https://www.perplexity.ai) as an org admin.
2. Open your organization settings, under **Data and Privacy → Audit Log Settings**.
3. Paste the **webhook URL** and **bearer token** you copied from Origin into the corresponding fields.
4. Save the settings.
![Perplexity's organization Data and Privacy settings, showing Audit Log Settings with the Webhook URL and Authorization Header fields.]()
## What to expect after connecting
Once both sides are configured, Perplexity audit log events flow into Origin as they happen and appear in your traces, analytics, and inventory alongside the rest of your captured AI activity. No further setup is required.
## Changing or removing the connection
* **Rotate the token:** Click **Rotate Token** again in Origin's **Data Sources** settings, then paste the new token into Perplexity's **Data and Privacy** settings. The old token stops working as soon as you rotate.
* **Disconnect:** Remove the webhook URL and token from Perplexity's **Data and Privacy** settings. New activity stops arriving in Origin; data already captured is unaffected.
## Troubleshooting
| Symptom | Likely cause | Resolution |
| - | - | - |
| No **Audit Log Settings** or webhook option in Perplexity | Organization doesn't meet the plan/seat requirement | Confirm you have 50+ Enterprise Pro seats, or upgrade at least one seat to Enterprise Max. |
| No Perplexity activity appears in Origin | The webhook URL or bearer token wasn't saved correctly in Perplexity | Re-check **Data and Privacy → Audit Log Settings** in Perplexity and re-paste both values from Origin's **Data Sources** page. |
| Activity stopped arriving after previously working | The token was rotated in Origin but not updated in Perplexity | Copy the current token from Origin's **Data Sources** page and update it in Perplexity's **Data and Privacy** settings. |
| Can't find the Perplexity entry under Data Sources | Your Origin role may not have admin access | Confirm you're signed in as an Origin admin; only admins can view and manage **Admin Settings → Data Sources**. |
| Perplexity Desktop or local usage doesn't show up in Origin | Expected — Perplexity is only captured via the organization-level webhook | There is no endpoint-based capture path for Perplexity; local/desktop usage isn't covered. |
## What Origin accesses
* Origin only **receives** audit log events that Perplexity sends to the webhook — it does not query or pull anything from Perplexity directly.
* The bearer token authenticates incoming requests to Origin's webhook endpoint; it does not grant Origin any access back into your Perplexity organization.
* The token is **shown only once** when generated or rotated, and Origin does not display it again afterward.
This integration is coming soon. Setup steps, required plan, and field names are subject to change before general availability.
# Endpoint Overview
Source: https://docs.originhq.com/product/registered-endpoints
View every device where the Origin agent has reported in — search and filter by hostname, user, AI tools, agent version, and hardware details.
The Endpoint Inventory is Origin's canonical list of every endpoint where the Origin agent has reported in. Each row represents one host and surfaces the key details you need to understand the device, its registered user, the AI tools installed on it, and the health of the Origin agent itself. Access the Endpoint Inventory by going to **Endpoints** in the main navigation — it's the **Overview** view, the first entry in the Endpoints panel.
## Search and Filtering
The **Search** box at the top of the table filters results in real time as you type. Your search runs across multiple fields simultaneously, including hostname, agent version, registered user, model, operating system, and other endpoint attributes — so you do not need to know which column a value lives in before you start searching.
A counter below the **Search** box always shows how many endpoints are currently visible versus the full total (for example, *200 shown 270 total*), so you can immediately see whether any filters are narrowing your view.
## Column Management
Click the **COLUMNS** button in the top-right corner of the table to choose which columns are visible. The button label shows the current state — for example, **6/19** means 6 of 19 available columns are turned on. Toggle individual columns on or off to focus the table on the fields most relevant to your current task, whether that is auditing AI tool installations or checking agent version coverage.
## Default Columns
The table opens with six columns visible by default.
| Column | Description |
| - | - |
| **Hostname** | The host's reported computer name |
| **Last Seen** | Date and time the endpoint last checked in; the table sorts by this column by default |
| **Operating System** | The platform — macOS or Windows |
| **Registered User** | The user account associated with this endpoint at the time of its last check-in |
| **Agent Version** | The version of the Origin agent currently running on this host |
| **Installed AI** | AI applications and tools that Origin has detected on the host |
## Additional Columns
Enabling additional columns via the **COLUMNS** toggle gives you access to a richer set of endpoint data, organized into three areas:
* **Hardware details** — serial number, manufacturer, model, processor, memory, and drive size
* **OS details** — operating system version and edition
* **Agent integrity** — the executable SHA256 hash and watchdog version, useful for verifying that the agent binary has not been tampered with
The table sorts by **Last Seen** by default, putting the most recently active endpoints at the top. Reverse the sort to bring the oldest check-ins to the surface and quickly identify stale or disconnected agents that may need attention.
# Role-Based Access Control: The Full Capability Matrix
Source: https://docs.originhq.com/product/role-based-access-control
What each of Origin's eight built-in roles can see and do: endpoints, event content, AI prompt text, analytics, directory data, signals, and tenant admin.
This is the detailed capability reference for Origin's eight built-in roles. It exists to answer one question precisely: *if I grant someone this role, what can they reach?*
For how grants work, how to invite users, and guidance on choosing between roles, see [User Management](/getting-started/user-management).
## The eight roles
| Role | Persona |
| - | - |
| **Tenant Admin** | Tenant owner / IT manager |
| **SecOps** | SOC analyst / security engineer |
| **Detection Engineer** | Detection content owner |
| **IT / Fleet Admin** | Endpoint / fleet administrator |
| **Viewer** | Auditor / exec / read-only |
| **Vendor Support** | External support engineer |
| **Security Engineering** | Platform / integration engineer |
| **No Data Access** | Familiarization / training |
These are the names as they appear in the role picker in **Admin → Access**.
Every role applies across the whole tenant. Nothing about a role is implicit — if a capability isn't granted below, that role can't reach it.
## Data-facing roles
Five roles work with monitored data. **Legend:** ✓ full access · ◐ read-only or limited · — no access
| Capability | Tenant Admin | SecOps | Detection Engineer | IT / Fleet Admin | Viewer |
| - | :-: | :-: | :-: | :-: | :-: |
| List & read endpoints | ✓ | ✓ | ✓ | ✓ | ✓ |
| Manage endpoints (revoke certs, etc.) | ✓ | — | — | ✓ | — |
| Endpoint metadata (OS, agent build) | ✓ | ✓ | ✓ | ✓ | ✓ |
| Sensitive endpoint metadata (installed software, processes) | ✓ | — | ✓ | — | — |
| Event metadata (time, source, severity) | ✓ | ✓ | ✓ | — | ✓ |
| Raw event payloads (command args, file content) | ✓ | — | ✓ | — | — |
| AI-session metadata (model, token totals) | ✓ | ✓ | ✓ | — | ✓ |
| AI prompt / response text | ✓ | — | ✓ | — | — |
| Aggregate analytics | ✓ | ✓ | ✓ | — | ✓ |
| Row-level analytics export | ✓ | — | ✓ | — | — |
| Read directory data (users, groups, devices) | ✓ | ✓ | ✓ | ✓ | ✓ |
| Sensitive directory data (name, email, phone, manager) | ✓ | — | ✓ | — | — |
| Request endpoint telemetry | ✓ | — | — | ✓ | — |
| Manage provisioning tokens | ✓ | — | — | ✓ | — |
| Read detection signals | ✓ | ✓ | ✓ | — | — |
| Manage / deploy detection signals | ✓ | — | ✓ | — | — |
| Read the tenant audit log | ✓ | ✓ | ✓ | ✓ | ✓ |
| Manage users & roles | ✓ | — | — | — | — |
**Detection Engineer** is the only non-admin role that reads AI prompt text, raw event payloads, and directory PII. Everything SecOps can do, it can do — plus the content needed to write and tune detections.
## Operational and limited roles
These three are defined by what they *can't* reach, so they're listed separately rather than as mostly-empty columns.
| Capability | Vendor Support | Security Engineering | No Data Access |
| - | :-: | :-: | :-: |
| Sign in & navigate the dashboard | ✓ | ✓ | ✓ |
| List endpoints & read metadata | ✓ | — | — |
| Read agent health / request telemetry | ◐ | ✓ | — |
| Read installers & download URLs | ✓ | ✓ | — |
| Integration / connector config | ◐ | ✓ | — |
| Configure integrations & run syncs | — | ✓ | — |
| Read / write tenant configuration | — | ✓ | — |
| Read detection signals | — | ✓ | — |
| Read the tenant audit log | ✓ | ✓ | — |
| Events / AI sessions / analytics | — | — | — |
| Manage users, roles, destructive settings | — | — | — |
## Sensitive surfaces
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 requires 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.
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.
For the exact permission strings behind any capability not listed above, contact Origin support.
# Dashboard: Origin's Built-in Dashboards and Chat Interface
Source: https://docs.originhq.com/walkthroughs/dashboards
Six built-in Origin dashboards for security posture, AI usage, adoption, shadow AI, tools, and token spend, plus a chat interface for plain-language queries.
**Dashboard** is the first view in the icon rail — sometimes called the Analytics Graph, after the data model it queries. It has two halves: a set of out-of-box dashboards down the left, and a free-form chat interface that queries your tenant in plain language.
![The Analytics Graph view showing dashboards, saved chats, and starter prompts]()
## Dashboards
Six dashboards ship with the product, listed at the top of the left panel:
| Dashboard | What it covers |
| - | - |
| **Security posture** | A CISO view of observed AI coverage, exposure, use, governance evidence, and policy enforcement gaps |
| **AI usage overview** | AI activity, agent surfaces, providers, and models in the current scope |
| **Adoption & concentration** | Usage concentration, tool adoption, and newly observed models |
| **Shadow AI** | AI providers, models, and agent surfaces in scope, including first-seen ones |
| **Tools & resources** | Tools and resources used by agents, with security signal findings |
| **Token spend** | Tenant-wide token volume by model and client surface |
Most dashboards follow the current scope. **Token spend does not** — it reports tenant-wide figures and does not narrow when you scope in. For scoped cost, use the **Token volume** series on the Explore activity surface.
Dashboards are canvases. The same object appears as a tab in [Explore](/walkthroughs/explore) rendered against your current scope, and is edited in the [Library](/walkthroughs/library).
## Ask the Analytics Graph
The chat interface queries the tenant data you can access and renders results as tables, charts, and canvases inline.
Access is bound by your role — the agent only reaches data your grants already allow, so two people can legitimately get different answers to the same question. See [Access Control](/product/role-based-access-control).
### Starter prompts
Six starters sit on the empty state, each a real query you can run or edit:
| Starter | What it asks |
| - | - |
| **AI activity by use case** | Leading use cases over the last 30 days, grouped by week |
| **MCP tool adoption** | MCP tools spreading across endpoints over eight weeks |
| **Skill adoption** | Agent skills appearing and disappearing over 30 days |
| **Token usage** | Token usage, coverage, and highest-cost submissions over seven days |
| **New since last week** | New MCP servers, tools, models, providers, and endpoints |
| **AI usage concentration** | Prompt and tool-call concentration by endpoint and user |
Notice how specific the starters are — each names a window, a grouping, and often a rendering ("make the cluster cells clickable", "build it as a canvas"). Questions phrased that way produce far better answers than open-ended ones, and you can ask for an interactive result or ask it to persist the answer as a canvas.
**Profile your AI usage** sits below the starters and tailors suggestions to what your organization actually does with AI.
### Chats
Conversations are saved in the **Chats** list with a relative timestamp, so an investigation can be picked up later. **New chat** starts a fresh one, and chats open as tabs so several can run side by side.
# Explore: Visual Analysis of AI Activity in Origin
Source: https://docs.originhq.com/walkthroughs/explore
Explore visualizes AI activity in four sub-views (Overview, X-Ray, Anatomy, Canvases), with break-down and steering controls to scope into any slice.
**Explore** is the visual exploration view. It has four sub-views down the left — Overview, X-Ray, Anatomy, and Canvases — and all four render against the current **scope**.
![The Explore view showing headline counts and the activity surface]()
## Setting the scope
Three controls determine what the four views are looking at.
### Date range
The selector at the top left sets the window every view uses. If a view looks empty, check this first — a scope with no activity in the window renders as zeros, not as an error.
### Break down by
Below the view list, **Break down by** lists the nine entity types Origin tracks, each with a live count:
| Entity | What it is |
| - | - |
| **Agents** | AI agent surfaces observed — Claude, ChatGPT, Copilot, Cursor |
| **Endpoints** | Managed devices reporting in |
| **Identities** | The people behind the activity, via your directory integration |
| **Models** | Specific models invoked |
| **Clusters** | Prompts grouped into topics |
| **Sessions** | A continuous unit of work — the unit of investigation |
| **Tools** | Individual tool calls made by agents |
| **MCP servers** | MCP servers agents connected to |
| **Skills** | Agent skills observed in the field |
| **Signals** | Detection signals that fired against prompts in scope — opens as an alert console |
Expanding one gives a searchable, sortable inventory. Sessions, for example, ranks by activity:
![The All sessions inventory ranked by activity]()
Clicking any row **scopes into it**. The breadcrumb updates, the headline counts drop to that slice, and all four views recalculate:
![Explore scoped into a single session]()
This is the core loop: break down by an entity, find the row you care about, scope into it, then read the four views.
### Steer this scope
**Steer this scope…** opens a filter builder for conditions you cannot express by clicking one row — **Match** (`ALL (AND)` or any), **+ Condition**, **+ Group** for nested logic, and a **Query** field showing the text form. **Apply** re-scopes; **Cancel** leaves it untouched.
## Overview
The default view. Three headline counts — **Requests**, **Active endpoints**, **Sessions** — sit above the **Activity surface** chart, which plots volume over time broken out by agent, with four series tabs:
* **Active endpoints** — how many machines were active
* **Active sessions** — how many units of work were running
* **Prompt volume** — raw prompt count
* **Token volume** — token throughput, the closest proxy for cost
Range buttons run **1D**, **5D**, **1M**, **1Q**, and up.
Switching between **Prompt volume** and **Token volume** is the quickest way to spot a few sessions consuming a disproportionate share of spend — a flat prompt line under a spiking token line means fewer, much larger requests.
### Request log
Below the chart, every request in scope, newest first:
![The request log with search, totals, and per-request rows]()
A totals line summarizes the whole scope, not just visible rows:
```text theme={null}
200 shown 392.6K+ total 35.3B in 432.4M out 35.7B total ≈$100.5K on 124.2B processed (90% priced)
```
The search box takes free text and field filters, with wildcards in values:
```text theme={null}
agent:anthropic cluster:auth endpoint:*-prod
```
Requests still in flight show as **Pending** with an `unknown` model until they resolve.
Log search filters the log only. To point every view at a narrower slice, change the scope instead.
## X-Ray
Overview tells you *how much*; X-Ray tells you *what it is about*, by reading prompt text in scope and rendering the language back.
![The X-Ray term arc diagram]()
X-Ray reads a **sample**, not everything. The line above the tabs states exactly what it looked at — for example `Scanning a window of 120 prompts across 3 sessions · 289 distinct terms` — and a Sample control at the bottom sets the size and shows where the window sits in the total.
Tabs offer many different readings of that window — **Terms**, **Topic patterns**, **Describe**, **Workflows**, **Wiki**, **Behaviours**, **Lineage**, **Linear**, **Research**, **Git**, **Grafana**, **Queries**, **Recall**, **Artifacts**, **Live**, and **Secrets** — with an overflow menu (`···`) once there are more tabs than fit the strip.
On the default Terms tab, terms sit around an arc sized by frequency. Ribbons link terms that appeared in the same prompts, hovering traces one term's links, and selecting a term filters the log beneath to just those prompts — the bridge from "this topic is prominent" to "show me the requests".
X-Ray is most useful right after narrowing scope. Run it on the whole tenant and you get generic vocabulary; run it on one cluster, endpoint, or session and the terms become specific enough to act on.
## Anatomy
Anatomy answers "where does this activity actually sit" — the structure of the scope rather than its totals or its language.
![The Anatomy view showing Structure and Discover with the position breadcrumb]()
Two tabs split it: **Measured — Structure** (what Origin measured directly) and **Scouted — Discover** (what it scouted).
Under **Position**, the **Where you are** panel places the current scope in the hierarchy, starting at `GLOBAL · All activity`. Its caption describes what it did:
```text theme={null}
from the global scope, auto-drilled down the busiest branch · click any cell to jump there
```
Origin has already walked down the heaviest branch under **Highest-volume descent** rather than making you click through it. Every cell is clickable and re-scopes the console to that branch.
Below Position, a **Composition — What your organization runs on** section breaks the scope down by endpoint, identity, and agent, with a one-line concentration read — for example, *"Concentrated. `joe@originhq.com` drives \~66% of your organization. Likely one machine's workflow."*
## Canvases
Canvases are multi-widget views assembled from kernels, shown as tabs across the top:
![The Canvases view showing the AI usage overview canvas]()
The six built-ins are the same objects as the dashboards in the [Dashboard](/walkthroughs/dashboards) view — **Security posture**, **AI usage overview**, **Adoption & concentration**, **Shadow AI**, **Tools & resources**, and **Token spend**. The difference is that here they render against whatever scope you have built.
Each canvas is a stack of widgets, and widgets are attributed — built-ins are labeled `by Origin`. To create or edit one, see the [Library](/walkthroughs/library).
# How the Origin Console Is Organized: Six Primary Views
Source: https://docs.originhq.com/walkthroughs/how-origin-is-organized
The Origin console has six sections: Dashboard, Explore, Library, Endpoints, AI Governance, and Admin. Learn what each one does and when to use it.
The Origin console is organized into six sections, listed down the far-left icon rail:
* **Dashboard** — out-of-box dashboards (built on the underlying **Analytics Graph** data model) plus a free-form chat interface for querying anything in the system in plain language.
* **Explore** — a visual exploration of activity within Origin, letting you set a scope and drill down by agent, identity, endpoint, and other attributes.
* **Library** — a management interface to create, save, and edit kernels (saved queries), canvases (dashboard pages), and workflows.
* **Endpoints** — the endpoint inventory, the quick-connect flow for provisioning tokens and installers, and fleet-wide agent configuration.
* **AI Governance** — tenant-wide policy: which AI services are sanctioned, unsanctioned, or ignored, and the detection rules that fire signals against monitored activity.
* **Admin** — tenant setup and configuration: users and roles, directory connections, and external AI data sources.
## Where to go next
Out-of-box dashboards and the free-form chat interface for querying anything in the system.
Visual exploration — Overview, X-Ray, Anatomy, and Canvases, with drill-down by agent, identity, and endpoint.
Create, save, and edit kernels (saved queries), canvases (dashboard pages), and workflows.
Endpoint inventory, agent connect flow, and fleet-wide configuration — covered under Setup and Configuration.
Users and roles, directory integrations, and AI data sources — covered under Setup and Configuration.
**AI Governance** doesn't have a dedicated guide yet. It's where sanctioned/unsanctioned AI policy and detection rules live — reach out to your Origin contact if you need help configuring it in the meantime.
# Library: Manage Kernels, Canvases, and Workflows in Origin
Source: https://docs.originhq.com/walkthroughs/library
The Library is where you create, save, and edit the building blocks behind Origin views: kernels (saved queries), canvases (dashboard pages), and workflows.
The **Library** is where the building blocks behind every saved view are managed — kernels, canvases, and workflows.
![The Library showing kernel, canvas, and workflow counts with recent items]()
The overview opens with a count of each:
| Object | What it is |
| - | - |
| **Kernels** | Deterministic recipes — saved queries that always return the same shape of result |
| **Canvases** | Multi-widget views assembled from kernels |
| **Workflows** | Automations, created from the **+** menu |
## Kernels
A kernel is a named, saved query. Each has a path-style name, a one-line description, and an attribution:
```text theme={null}
/local-ai-summary
Local AI on endpoints (30d) · built-in
by Origin
```
Kernels shipped with the product are marked `built-in` and attributed `by Origin`. Ones your team writes carry your own attribution and can be edited.
### Why deterministic matters
The Analytics Graph answers free-form questions, and two similar questions can produce differently shaped answers. A kernel is pinned. That makes kernels the right tool when a number has to be comparable over time — a weekly report, a compliance figure, a widget on a shared dashboard — and the chat interface the right tool for open-ended investigation.
A good working pattern: explore in [Dashboard](/walkthroughs/dashboards) until you have a question worth tracking, then capture it as a kernel so the answer stays stable and can be dropped onto a canvas.
### Built-in kernels worth knowing
| Kernel | Use it for |
| - | - |
| `/local-ai-summary` | Which endpoints are running local AI |
| `/local-ai-detail` | The same, broken down per endpoint |
| `/local-ai-evidence` | How that detection was actually made |
| `/new-agent-surfaces` | Agent surfaces seen for the first time |
| `/agent-surfaces` | The full set of agent surfaces (harnesses) in use |
| `/model-mix` | Which models are carrying the work |
| `/activity-summary` | A general activity rollup |
## Canvases
A canvas is a multi-widget view assembled from kernels. Each entry shows its name, description, kernel count, and age:
```text theme={null}
/ai-usage-overview
AI usage overview 5 KERNELS · 223D AGO
```
That kernel count tells you how much is behind a canvas before you open it, and which kernels to check if a widget shows something unexpected.
The same canvas is reachable from two places, and the difference matters:
| Route | Behavior |
| - | - |
| **Explore → Canvases** | Renders against whatever scope you have built |
| **Dashboard** (left panel) | Direct route, without setting up a scope first |
Not every canvas follows scope. Widgets reporting tenant-wide figures — **Token spend** is the built-in example — ignore the current scope by design.
Before building a new one, check the built-in six — Security posture, AI usage overview, Adoption & concentration, Shadow AI, Tools & resources, and Token spend already cover the most common governance, adoption, and cost questions.