Overview

Blindsight DLP is the endpoint 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. 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.

​

DLP 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. You usually want both. Runtime Security gives the application team tight control over its own LLM surface; DLP catches everything else.

​

Why endpoint, not just network

A network-perimeter DLP (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 DLP 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.

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.

​

What it covers, what it doesn’t

DLP 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