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

# Overview

> Protect AI traffic on the device. A signed desktop agent intercepts LLM calls at the OS network layer and routes them through Blindsight so nothing reaches a public model unscanned.

Blindsight Endpoint is the **device** half of the runtime story. A
desktop agent runs on every employee laptop (Windows and macOS),
intercepts outbound LLM traffic on the device, and routes every
prompt through Blindsight for verdict and policy enforcement before
the bytes leave the machine.

> [!NOTE]
>
> Windows and macOS are both supported, and the console's Downloads
> page publishes installers for both. They enrol differently: the
> Windows MSI carries a fleet token and enrols silently, while a Mac
> enrols when its user signs in. The macOS coverage model also differs.
> Read [Installing the agent](https://docs.blindsight.io/endpoint/install.md) before committing to a Mac
> fleet.

It's the right answer when you cannot rely on every internal team to
wire SDK-level Runtime Security on their own. Once the agent is
pushed by your MDM, every prompt to every public model on every
managed device is covered, automatically, without changing a line of
application code.

## Endpoint vs Runtime Security

The two surfaces share the same scanners, the same Apps, the same
event store. They differ in **where the traffic is intercepted**.

| Dimension | Runtime Security (SDK) | Endpoint |
| - | - | - |
| **Where it intercepts** | In your application code (proxy `base_url`, scan API, tool calls). | At the OS network stack on every managed laptop. |
| **Who deploys it** | The application team that owns the LLM call. | IT, once, via MDM (Jamf, Kandji, Intune, GPO, SCCM). |
| **What it covers** | Your own apps that you instrumented. | Every browser tab, every IDE plugin, every third-party desktop app. |
| **Identity** | API key + App ID per traffic source. | SSO-bound device + directory user, per machine. |
| **Code changes** | Yes (one config value for proxy, two HTTP calls for scan API). | None. |
| **Best for** | Apps you own and want fine-grained policies on. | Shadow-IT AI traffic from tools you don't control. |

You usually want **both**. Runtime Security gives the application
team tight control over its own LLM surface; Endpoint catches everything
else.

## Why endpoint, not just network

A network-perimeter tool (a SWG or CASB) can route HTTPS through an
inspection point, but it cannot:

* **See identity per session.** Every prompt from your fleet looks
  like the same egress IP. With the agent, every prompt is bound to
  the directory user whose laptop sent it.
* **Survive on Wi-Fi off-corporate-network.** Endpoint coverage
  follows the user, the home office, the coffee shop, the airport.
* **Scan inside applications that pin TLS.** The agent installs your
  organisation's root CA on the device, so it can MITM TLS without
  client co-operation.

The endpoint also gives you a tamper-evident posture: the agent
reports its own integrity events to the cloud (`/agent/tamper-events`).

## How it fits together

1. **IT pushes the agent** via MDM. One enrollment token covers the
   whole fleet.
2. **The agent self-enrolls** on first boot and runs the SSO
   device-code flow to bind the device to a directory user.
3. **The OS network layer routes** every outbound LLM call (OpenAI,
   Anthropic, Gemini, Vertex, Bedrock, and the OpenAI-compatible
   ecosystem) through the agent's local proxy.
4. **The agent fetches centrally-managed policy** from
   `/agent/policy`, runs local TLS MITM with the org root CA, and
   POSTs each prompt to `/agent/scan` for a verdict.
5. **Allow / redact / block** is enforced on the device, exactly the
   same verdict logic as the SDK paths.

The backend integration uses dedicated `agent/*` endpoints that share
the same scanners, the same App config, and the same event log as
in-app Runtime Security. Dashboards show endpoint traffic alongside SDK
traffic, attributed to the device's directory user.

## Inspection and discovery

The agent does two different jobs, and it's worth keeping them apart.

* **Inspection.** For the AI hosts you have onboarded, the agent
  MITMs the connection with the org root CA, scans the prompt, and
  enforces the verdict. You see content, verdicts, and redactions.
* **Discovery.** For every *other* AI destination, the agent records
  the hostname only, no decryption. That inventory is **Shadow AI**:
  the services your workforce reaches without approval, ranked by
  risk, each awaiting a decision to sanction, block, or onboard.
* **Protection.** A third posture in between: the agent inspects and
  pseudonymizes traffic to a service nobody has approved, and never
  blocks the person for using it. See
  [Protect unapproved AI](https://docs.blindsight.io/endpoint/shadow-ai/overview.md#protect-unapproved-ai).

Which of these a workspace runs is its own choice, made in
[Protections](https://docs.blindsight.io/endpoint/protections.md): prompt injection detection,
personal data protection and Shadow AI each switch on or off
independently.

Discovery is what you run first. It answers "which AI is this company
actually using?" without touching anyone's traffic, and it produces
the list that tells you what is worth inspecting. See
[Shadow AI](https://docs.blindsight.io/endpoint/shadow-ai/overview.md).

## What it covers, what it doesn't

Endpoint catches LLM traffic from any managed device, including:

* Browser tabs (ChatGPT, Claude, Gemini, Perplexity, ...).
* IDE plugins (Copilot Chat, Cursor, Continue, ...).
* Native desktop apps (Claude Desktop, ChatGPT desktop, ...).
* CLI tools that hit a public LLM API.

It does not cover:

* Unmanaged devices (personal phones, contractor laptops without the
  agent). Use SSO + conditional access for those surfaces.
* LLM traffic that never leaves your network (a private model on your
  own VPC). Use the SDK reverse proxy in those services.

## Where to next

> **[Installing the agent](https://docs.blindsight.io/endpoint/install.md)**
>
> Packages, silent install, what it changes on the machine, and how
> to verify it landed.

> **[Uninstalling the agent](https://docs.blindsight.io/endpoint/uninstall.md)**
>
> Clean removal on Windows and macOS, and what an uninstall
> permanently destroys.

> **[Shadow AI](https://docs.blindsight.io/endpoint/shadow-ai/overview.md)**
>
> Passive discovery of every AI service your workforce reaches, and
> a sanction / block / onboard decision for each one.

> **[Fleet rollout](https://docs.blindsight.io/endpoint/fleet-rollout.md)**
>
> MDM push for macOS and Windows. One enrollment token, the agent
> self-enrolls on every device.

> **[Identity binding](https://docs.blindsight.io/endpoint/identity.md)**
>
> SCIM directory sync, OIDC SSO, and the device-code flow that
> binds each laptop to a directory user.

> **[Devices & enrollment](https://docs.blindsight.io/endpoint/devices.md)**
>
> The fleet view: device status, identity binding, tamper events.

> **[Protections](https://docs.blindsight.io/endpoint/protections.md)**
>
> Choose which of injection detection, personal data protection and
> Shadow AI devices run.

> **[Who is named in the console](https://docs.blindsight.io/endpoint/who-is-named.md)**
>
> Named, coded, or counts only: how much of what devices see is tied
> to a person.

> **[Policies & agent API](https://docs.blindsight.io/endpoint/policies.md)**
>
> Centrally-managed AI host rules and the backend endpoints the
> agent calls.

> **[Endpoint permissions](https://docs.blindsight.io/endpoint/permissions.md)**
>
> The `endpoint.` permission keys, the two endpoint roles, and what
> each key grants.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.