Overview
Loading executive summary…
AI risk posture
Risk breakdown
By category
How detection works — and what we do not read
The endpoint sensor is observe-only and content-blind. It does not read your prompts, chat transcripts, or the code you paste into an AI tool. It flags risk from artifacts and behaviour it can see locally:
• API keys — matched by pattern (e.g. sk-…, AWS/Anthropic/Groq formats) where credentials sit on disk: .env, dotfiles, shell history, credential stores.
• AI tools — installed CLIs/IDEs/extensions, .mcp.json configs and running MCP servers.
• Egress — network connections to known AI/model endpoints (destination + SNI only, not payload).
Inspecting the content of a prompt or paste (true DLP on what’s typed into an assistant) requires the optional browser DLP extension / egress proxy — a separate, explicitly-deployed component, not the base sensor.
Flagged unsanctioned · Pending not yet triaged · Sanctioned approved by policy · Clear benign. Filter to focus a review; sanctioning here feeds the approved-AI policy.
| Risk | Machine | Category | Name | Detail | Status | Seen | Source | Feedback |
|---|
Triaged risks aren’t deleted — they move to their status. Actionable hides only false positives; pick a status to find acknowledged / accepted / resolved / muted items, then reopen any of them from its detail.
| Severity | Class | Risk | Machine | Status | Last seen |
|---|
Map your live AI risk posture to the standards and regulations your buyers and auditors ask about — AI-specific and general security/privacy. Open a framework for detail and coverage, then generate a report in the format you need. This is control-implementation evidence, not a certification.
Two lenses on every AI threat: the operational risk to your organization, and the active-threat severity — how likely and dangerous exploitation is right now. A continuous engine pulls AI CVEs (NVD / CISA KEV / OSV) and curated agent TTPs and correlates them against your fleet, alerting you on Slack + email the moment a new High/Critical exposure appears.
Continuous threat-intel engine
Live exposures — catalog matched to your inventory; threat severity is capability-specific. Click a row for the scoring rationale.
| Threat | Capability | Host | What matched | Source | Status |
|---|
Detected activity mapped to MITRE — Threat (active) vs Risk (operational) shown side by side. Click a row for precedents + why.
| Threat | Risk | Sensor | User | IP | Activity | ATLAS / ATT&CK | Actor |
|---|
Intel catalog & analyst review queue — new AI CVEs + curated agent TTPs. Curated items are recommendations for a human to promote; the engine never auto-changes detection rules.
| Threat | Source | Capability | Title | TTP |
|---|
MITRE technique coverage — techniques your open risks map to
| Framework | Technique | Name | Tactic | Open risks |
|---|
APT groups weaponising AI — state actors observed abusing LLM/AI tooling (MS/OpenAI, 2024)
| Actor | Also known as | Attribution | Observed AI use | ATLAS |
|---|
What is “vibe coding”, and why is it a security concern?
Vibe coding is building software by prompting AI assistants — Cursor, Claude Code, GitHub Copilot, Windsurf, MCP agents — instead of hand-writing each line. It is fast and now everywhere, but the AI ships plausible-looking code that routinely contains injection flaws, hardcoded secrets, broken authorization and vulnerable dependencies, and it often reaches production without a human security review.
This view answers the questions a security reviewer actually asks: who is vibe coding, from what kind of account, on which machine, and — most importantly — in which project (name + path), so you can point a focused code review at exactly the right repositories.
| Severity | Project | Path | Developer | Account | Machine | AI tools |
|---|
Developers
| Developer | Account | Machines | Projects | AI tools | Exposure |
|---|
AI coding assistants in use
IDE-embedded AI coding assistants
| Assistant | Vendor | IDE | Version | Machine | User | Account | Type | Egress |
|---|
Guidance
Your other tools see AI artifacts as a flat list. The risk is in how they connect: an autonomous agent, wired to an over-privileged MCP tool, holding a live credential, reaching an external model. This view assembles the connected capability path — device → AI app → agent → MCP → tool → credential → egress — for every endpoint.
A path becomes an active threat when autonomy × privilege × reach line up. Each path is scored on the audited per-capability rubric, so the severity decomposes into the exact factors that drove it — nothing is a black box.
Model Context Protocol (MCP) is how AI agents reach real systems — filesystems, databases, shells, GitHub, cloud. The wiring lives in a config file on the endpoint, which is where the sensor reads it. A connected MCP server can hide instructions in its tool metadata (tool poisoning) to make the agent leak secrets or run commands, so every server is untrusted code with the agent's access.
This view inventories every MCP server on your fleet: which agent loads it, what it can reach (blast radius), and its supply-chain risk — unpinned versions (silent rug-pulls) and packages fetched from the internet at launch.
| Risk | Server | Client | Reach | Version | Supply chain | Hosts |
|---|
AI keys and the agents that use them are non-human identities (NHIs): they hold real access, can't do MFA, rarely rotate, and are seldom retired. In most enterprises they now outnumber human accounts many times over — and one leaked agent credential is broad, persistent access.
This view inventories every AI/cloud credential and agent identity on the fleet, who owns it (enterprise / personal / service / shared), how old it is, and the governance flags that matter: orphaned (no human owner), shared, personal, and stale (long-lived, likely unrotated).
| Severity | Identity | Provider | Type | Owner | Host | Age | Flags |
|---|
Guidance
Define which AI tools are approved for your org. Everything discovered is then shown as approved, unsanctioned, or blocked. Block a specific tool or model (e.g. DeepSeek) and — with enforcement on — sensors will block it fleet-wide on their next cycle.
Approved AI tools — one per line or comma-separated
Blocked tools / models — names
Blocked domains — egress hostnames
Enforcement modifies the endpoint (null-routes denied hostnames, terminates denied processes). Strongest on Linux. Leave off to observe-and-report only.
Inline AI-DLP — prompt content control — blocks/redacts sensitive data pasted into AI tools
The browser DLP extension / egress proxy calls the platform before a prompt leaves the endpoint. Pick an action per data class and a rollout mode. Monitor logs and warns only — safe to start; Enforce actually blocks or redacts. This is the content-inspection channel; the endpoint sensor stays observe-only.
Blocked AI destinations — hostnames; prompts to these are blocked
Data retention & governance — how long this tenant's data is kept
Set a retention window so raw findings and audit records are automatically purged after a period — a common data-governance and privacy requirement. Minimum 30 days. Open risks are never deleted; risks are recomputed after a purge so aged-out ones drop while current ones stay. Preview before you apply.
Scheduled reports — emailed posture summary on a cadence
Email a posture summary — risk score, open risks by severity, top items, and a link to generate the full compliance report — to stakeholders on a schedule. Uses your tenant's data only.
Discovered AI tools by status
Encrypted evidence export — chain-of-custody, tenant-isolated
Download this tenant's logs as an AES-256-GCM encrypted batch. Each tenant's data is encrypted under its own key (HKDF-SHA256 from a master secret held outside the database), so another tenant's key can't read it and any tampering fails verification. Hand it to a client as an encryption challenge, or archive it for chain of custody. Data is TLS-protected in transit and the store sits on an encrypted-at-rest volume.
Risks triaged as false positives — moved off the main board, retained for audit. Each keeps its full comment trail (who marked it, why, and every edit since).
| Severity | Class | Risk | Machine | Marked by | Notes |
|---|
People ranked by AI-risk exposure. Enrich with your IdP to add name, department, and employment status.
| Person | Department | Status | Devices | Open risks | Posture |
|---|
Every triage, comment, false-positive, directory sync, and quarantine — who did what, when. The tamper-evident record for auditors.
| When | Actor | Action | Detail |
|---|
Push new AI-risk findings straight into the tools your team already lives in. Each tenant has its own Slack / Jira / SIEM connection — secrets are encrypted at rest and never shared across orgs.
Accounts with dashboard access. Roles: Owner (full + assigns roles), Admin (users, policy, integrations), Analyst (triage & respond), Viewer (read-only). Platform Admin is Shadow AI staff (cross-tenant).
Single sign-on (SSO) & SCIM offOkta · Entra ID · Google · Auth0 — OIDC
Let your identity provider handle login. Enterprise IdPs do MFA and lifecycle; users are just-in-time provisioned on first sign-in and mapped to a role by their IdP group. Configure an OIDC app in your IdP with redirect URI https://…/auth/sso/callback.
Custom roles & permissions 0Owner-defined roles with a chosen set of tools
Build a role from individual permissions, then assign it when you create or edit a user. The four built-in roles (Viewer · Analyst · Admin · Owner) can’t be changed; custom roles layer on top and are scoped to this organization.
| User | Role | MFA | Status | Last login |
|---|
| Status | Machine | Sensor ID | OS | IP | User | Enrolled | Last seen | Agent |
|---|
Install the read-only Shadow AI sensor on your endpoints. Set COLLECTOR_URL to your dashboard and SENSOR_KEY to your tenant enroll key, then deploy via MDM/Intune/Jamf/Ansible. Existing sensors keep running when you update.
Organizations
Each row is one customer organization — click to open its details (org ID, license, sensors, chain of custody). Built to stay usable across hundreds of tenants: search by name or subdomain.
| Organization | Plan | License | Sensors |
|---|
Provision a new tenant
Creates the org and its unique enroll key. Configure that key as the sensor's SENSOR_KEY to bind endpoints to this tenant.
| Tenant | Plan | Status | Days left | Expiry | Active users | Users | Devices | Last active | Actions |
|---|
Active = license valid >30 days · Expiring = within 30 days · Expired = past due. A reminder email goes out automatically ~30 days before expiry.
AI usage on managed phones and tablets (iOS / iPadOS / Android) — the devices companies issue to avoid BYOD, and that frontline and field teams rely on. For each device: the AI apps and browser LLMs in use, which account (enterprise / personal / service / shared), and the network context — enterprise, home, or mobile. Off-enterprise-network AI use is a key flag for regulated and high-security fleets.
| Device | Platform | User | Account | Network | AI apps | Last seen |
|---|
How mobile coverage works
Managed mobile devices report through an MDM connector (Microsoft Intune, Jamf Pro, VMware Workspace ONE) or the lightweight Shadow AI mobile agent, which enrols with your tenant key and posts installed AI apps, browser-based LLM usage, the signed-in account, and the network the device is on. Nothing is collected from personal BYOD devices you don't manage. Point your MDM connector at /api/mobile/ingest with your tenant enroll key to populate this view.
Submit a support ticket
Our support team and your organization's admins are notified by email, and you can track the ticket here.
- Don't paste passwords, API keys, tokens, secrets or personal data (PII/PHI) into the description.
- Screenshots: redact/black out any secrets, credentials, customer names or personal data first.
- Log files: replace real values (keys, hostnames, user data) with synthetic/placeholder data before attaching.
Your tickets
| Ticket | Subject | Severity | Status | Created |
|---|
Account
Sessions
Signing out everywhere invalidates every other browser or device you're logged in on. This session stays active.