MSP Shadow AI Governance Console

What Is This Console

Purpose, scope, threat model

The Shadow AI Governance Console is an MSP-facing security tool that detects unauthorized local AI model deployments on client endpoints. It surfaces processes, file paths, and network ports associated with Ollama, LM Studio, llama.cpp, Whisper, and other local AI runtimes — identifying which clients have active models, which endpoints are affected, and what data exposure risk those models create.

The console is built around the SentinelOne Deep Visibility API. Every detection, endpoint event, and process match is sourced from a real-time DV query sent to your S1 management instance via a backend proxy. Client data and event history rendered in the UI are populated from that query pipeline — not from independent EDR agents or a separate SIEM.

What the Console Is Not

This is not a standalone EDR or a SIEM. It does not generate its own telemetry — it queries SentinelOne's existing telemetry pipeline. It requires Deep Visibility to be licensed and enabled at the Site level for each client. For clients using Microsoft Defender (the Mu Manufacturing case in the demo data), the console displays a fallback indicator but does not actively query Microsoft Graph Advanced Hunting — that integration must be built separately in your proxy.

Intended Audience

Who uses it and how

Layout & Sections

Page structure, navigation, responsive breakpoints

The page is a single scrollable document with a sticky topbar, a fixed right-side dot navigation, an API status banner, a KPI strip, and five distinct content sections. Navigation between sections happens by scrolling, clicking topbar nav links, or clicking the right-side dot nav — all use smooth scroll to the section's anchor ID.

Responsive Breakpoints

API Audit Findings

Complete audit against official SentinelOne API v2.1 documentation

Finding 1 — runScan Was Pure Theatre (Fixed ✓)

The original runScan() used a setTimeout loop to animate progress text with hardcoded step descriptions. It made zero actual API calls — the "69 total events" message was fabricated. The overlay gave the visual impression of real scanning while doing nothing. This has been replaced with a real async fetch chain that calls your proxy at five sequential endpoints: sites, agents, dv/init-query, dv/query-status (polled until FINISHED), and dv/events. Falls back gracefully if the proxy isn't deployed yet.

Finding 2 — runQuery Was a Fake setTimeout (Fixed ✓)

The original runQuery() waited 1.2 seconds then displayed a fabricated response with a random queryId, hardcoded 342ms latency, and a random estimatedResults count. No real query was sent. The function is now an async fetch that POSTs to /api/shadow-ai/edr/sentinelone/dv/init-query, extracts the real queryId from the response, and displays the actual server response in the terminal. When the proxy isn't deployed, it shows the ready-to-send payload as reference rather than a fake result.

Finding 3 — All 6 Remediation Actions Were Toast-Only (Fixed ✓)

Every remediation action in the Deep Dive panel called only toast('Action queued: ...') with a 2-second color reset — no API call of any kind. All six actions are now routed through ACTION_ROUTES to specific proxy endpoints. See Section 12 for the full routing table and per-action API constraints.

Finding 4 — Invalid DSL Field: GPUUsage (Fixed ✓)

Finding 5 — Missing dv/query-status Poll Step (Fixed ✓)

The S1 Deep Visibility API is asynchronous — POST /web/api/v2.1/dv/init-query returns a queryId and status RUNNING, not results. You must then poll GET /web/api/v2.1/dv/query-status?queryId={id} until the status is FINISHED, then fetch results with GET /web/api/v2.1/dv/events?queryId={id}. The original scan flow skipped the status poll entirely. The API banner also did not show the dv/query-status or dv/events endpoints as distinct steps. Both have been added.

Finding 6 — Fake Live Simulation Interval (Fixed ✓)

A setInterval running every 6 seconds randomly incremented detection counts on clients that had detections, then called renderKPIs(). This had no connection to real data — it fabricated upward-trending metrics to simulate live activity. It has been removed. Detection count updates now only happen when a real scan completes.

Audit Summary

Proxy Architecture

Why a proxy is required and how it fits

SentinelOne's API requires an Authorization: ApiToken {token} header on every request. That token cannot live in browser-side JavaScript — it would be exposed to any user who opens DevTools. All S1 API calls are therefore routed through a backend proxy that holds the token server-side, validates dashboard requests, and forwards them to your S1 management instance.

The dashboard sends X-Dashboard: shadow-ai-gov on every request. Your proxy should validate this header as a lightweight shared-secret check before forwarding. For production deployments, add proper auth (JWT, session token, or mTLS) between the dashboard and proxy.

Multi-Tenant Site Isolation

Each client in the console maps to a SentinelOne Site — a tenant-isolated container within your S1 account. The siteId field (e.g. site_acme) is the S1 Site ID for that client. All DV queries use siteIds: [clientSiteId] to restrict results to that client's endpoints. Your proxy must map your internal client identifiers to real S1 Site IDs obtained from GET /web/api/v2.1/sites.

Token Scope

The S1 Service User token used by your proxy should be Account-scoped with Viewer role for read operations (sites, agents, DV queries). For remediation actions (disconnect, firewall-control), the Service User requires elevated permissions — either a separate token with the appropriate role, or a custom role with exactly the permissions listed in Section 07.

Auth — ApiToken

SentinelOne Service User token setup and scope requirements

SentinelOne uses Authorization: ApiToken {token} for all API requests. The token is generated from a Service User — not a console user account — and is scoped to Account or Site level. For an MSP, Account-level scope allows a single token to query all Sites within the account.

1. 01
   Create a Service User

   In the S1 Management Console: Settings → Users → Service Users → Actions → Create New Service User. Set an expiration date — SentinelOne recommends rotating tokens monthly or less. For MSP use, scope to Account level.
2. 02
   Assign Role

   For read-only DV operations (sites, agents, dv/init-query, dv/events): built-in Viewer role is sufficient. For remediation actions (disconnect, firewall-control): create a custom role with Endpoints → Disconnect from Network + Reconnect to Network + Firewall Control. Deep Visibility requires the Deep Visibility feature to be enabled in the Site policy.
3. 03
   Copy the Token Once

   The API token is shown only at creation time. Copy it immediately and store it in your vault (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, or your proxy's environment variables). It cannot be retrieved again — you must delete and recreate the Service User to get a new token.
4. 04
   Configure Your Proxy

   Set the token as an environment variable in your proxy runtime (S1_API_TOKEN). The proxy reads it at startup and injects it as the Authorization header on every forwarded request. Never hardcode the token in source code or pass it to the browser.

// Every S1 API request from your proxy must include:
Authorization: ApiToken {your_service_user_token}
Content-Type: application/json

// Example proxy injection (Node.js):
const headers = {
  'Authorization': `ApiToken ${process.env.S1_API_TOKEN}`,
  'Content-Type': 'application/json'
};

S1 Endpoint Reference

All SentinelOne API v2.1 endpoints used by this console — verified against official documentation

Deep Visibility Query Flow — Step by Step

1. 01
   POST dv/init-query

   Send query DSL string, date range, siteIds, and limit. Response: {data: {queryId: "abc123", status: "RUNNING"}}. Store the queryId.
2. 02
   Poll GET dv/query-status?queryId={id}

   Response returns status: "RUNNING" or status: "FINISHED". Poll every 2 seconds, max ~12 times. Most queries finish in 3–10 seconds. If not finished after 24s, the query may still be running — increase poll count or increase poll interval.
3. 03
   GET dv/events?queryId={id}

   Once status is FINISHED, fetch the results. Response: {data: [{processName, filePath, networkPort, computerName, ...}], pagination: {totalItems, nextCursor}}. Paginate using cursor if totalItems exceeds your limit.

// Step 1 — POST /web/api/v2.1/dv/init-query
{
  "siteIds": ["YOUR_SITE_ID"],
  "query": "ProcessName ContainsCIS \"ollama\" OR ProcessName ContainsCIS \"LM Studio\" OR ProcessName ContainsCIS \"llama-server\" OR ProcessName ContainsCIS \"whisper\" OR FilePath EndWith \".gguf\" OR NetworkPort IN (\"11434\",\"1234\",\"8080\")",
  "fromDate": "2026-02-01T00:00:00Z",
  "toDate":   "2026-03-22T23:59:59Z",
  "limit":    500
}

// Step 2 — GET /web/api/v2.1/dv/query-status?queryId=abc123
// Poll until: { "data": { "status": "FINISHED" } }

// Step 3 — GET /web/api/v2.1/dv/events?queryId=abc123&limit=500
// Returns matched events with full process and file telemetry

API Status Banner

Connection nodes, dot colors, and what each displays

The API status banner at the top of the page shows nine nodes rendered by renderApiBanner(). Each node shows a dot (green = live, yellow = mock/pending, red = error), a current value, and the specific API endpoint it represents. In the shipped version these are static — wire your proxy health-check responses into this function to show real-time connection status.

KPI Strip

Seven tiles — what each counts and where the data comes from

KPI tiles have a 2px top color bar, lift-and-shadow on hover, and cursor:default — they are display-only and do not open drawers or drill-down panels. In production, renderKPIs() is called after each completed scan cycle rather than on a timer.

Detection Grid

Client cards, risk levels, model tags, and stat cells

The client grid renders one card per entry in the clients array, filtered by the active filter bar state. Each card is clickable and toggles the Deep Dive panel inline below the grid. Cards are colored by risk level — a 2px top border in red (critical), orange (high), yellow (medium), or green (low).

Deep Dive Panel

Per-client event log, endpoint list, API payload preview, governance status

Clicking a client card opens the Deep Dive panel inline below the grid. The panel is a 2-column grid with four cards: Event Log, Affected Endpoints, API Call preview (terminal), and Governance Policy Status. Clicking the same card again or pressing the × button collapses it.

Remediation Actions

Six wired actions — API routing, S1 constraints, and what each proxy endpoint must do

POST /api/shadow-ai/actions/{slug}
Content-Type: application/json
X-Dashboard: shadow-ai-gov

{
  "action":     "isolate",
  "siteId":     "site_acme",    // null if no client is open in deep-dive
  "clientName": "Acme Corp",
  "timestamp":  "2026-03-22T14:00:00.000Z"
}

// Proxy response — optional, shown in toast if present:
{ "message": "3 endpoints isolated · Acme Corp" }

Analytics Charts

Five Chart.js 4.4.1 canvases — data sources and production wiring

All charts use a consistent tooltip theme: dark background (#0a0f18), JetBrains Mono title/body fonts, and subdued label colors to match the console aesthetic. Chart instances are stored in the chartInstances object. Charts are rendered once on init and not re-rendered on scan completion in the current version — add renderCharts() to the scan completion handler to refresh them with real data.

Query Builder

Preset selection, DSL textarea, execution, and payload preview

The Query Builder allows analysts to compose, preview, and execute SentinelOne Deep Visibility queries against any Site or the full portfolio. It is wired to POST real queries to your proxy — execute populates the terminal with the real queryId and response, while Preview shows the JSON payload without sending it.

Policy Status Table

Per-client AI governance compliance — how it's currently computed and how to source it live

The Policy Status table shows seven columns per client: Client/Site, Overall Status, AI Policy (written policy on file), S1 Rule (behavioral detection rule deployed), User ACK (employee acknowledgment), Incident (open PSA ticket), and Events. The overall status is derived from client.risk.

In the current version, all columns except Events are derived from client.risk using simple boolean logic — for example, hasPolicy = client.risk === 'low'. For production compliance tracking, these fields should be sourced from your GRC platform, PSA custom fields, or a separate policy management database. The table structure supports direct replacement of the computed values with real data from those systems.

Alert Feed

Detection alerts — demo data structure and production population

The Alert Feed renders the alertsData array — currently seven static entries covering the highest-severity findings across clients. Each entry shows: severity icon, client name, message, endpoint detail (↳ processName · hostname · context), and source metadata (platform, query method, age).

In production, populate alertsData from your DV events response after each scan. Group events by siteId, rank by severity (processes listening on 0.0.0.0 = critical, HIPAA-relevant models on clinical machines = critical, .gguf files = high, policy-violation ports = high, single session clean exit = medium). The endpoint detail and meta strings should be built from the DV event's agentComputerName, processName, and createdAt fields.

Deep Visibility DSL

Valid operators, queryable fields, and constraints confirmed against S1 v2.1 API documentation

Valid Operators

Queryable Fields (Process Events)

Query Limitations

Preset Query Library

Seven validated queries — what each detects and why

Defender Fallback

What it means, what it does now, and how to wire it

One client in the demo data — Mu Manufacturing — uses edr: 'defender'. This represents clients whose endpoints run Microsoft Defender for Endpoint rather than SentinelOne. The console displays a yellow "● Defender · Fallback EDR" badge for these clients and shows their static detection data — but does not actively query Microsoft Graph Advanced Hunting.

Microsoft Graph Advanced Hunting — KQL Equivalents

Proxy Endpoint Spec

Every path the dashboard calls — what your proxy must implement

Go-Live Checklist

Ordered steps from demo mode to production

1. 01
   Create S1 Service User and generate API token

   Account-scoped Viewer role for read operations. Create a second Service User with a custom role that includes Endpoints → Disconnect from Network and Firewall Control for remediation actions. Store both tokens in your vault.
2. 02
   Enable Deep Visibility on all client Sites

   In S1 Management Console: Sentinels → Policy → Deep Visibility → Enabled. DV must be both licensed and enabled per-Site. Without this, dv/init-query will succeed but dv/events will return empty results.
3. 03
   Deploy the backend proxy

   Implement all 10 endpoints from Section 20. Serve from the same origin as the dashboard HTML or configure a reverse proxy so relative paths resolve correctly. The token must live only in the proxy's environment — never in the browser.
4. 04
   Map client names to real S1 Site IDs

   Run GET /web/api/v2.1/sites via your proxy and map the returned site IDs to the client records in the clients array. Update the siteId values from the placeholder strings (site_acme, site_zeta, etc.) to your real numeric S1 Site IDs. Update the Query Builder's site dropdown options to match.
5. 05
   Wire renderClientGrid to DV event data

   After a scan completes, transform DV events into the client array shape (detections, models[], endpoints[], events[], gpuFlag, port11434, ggufFiles). Call renderClientGrid(clients) and renderKPIs() with the updated data. The cards and KPI tiles will reflect live scan results automatically.
6. 06
   Deploy action proxy endpoints

   Implement the six /api/shadow-ai/actions/* routes. Test each one manually before enabling in the console. The dashboard falls back gracefully if the routes aren't yet live — no frontend change needed when you add them.
7. 07
   Update API status banner to reflect real health

   Add a lightweight proxy health endpoint and call it from renderApiBanner() on page load. Update node dot classes (dot-live / dot-mock / dot-error) based on the health response rather than static strings.
8. 08
   Wire Analytics Charts to DV events data

   After a scan completes, aggregate DV event data into the chart shapes documented in Section 13 and call renderCharts() with the live data. The chart canvases and Chart.js instances are already set up — you only need to provide real data arrays.

FAQ

Common questions about wiring, limitations, and edge cases