Overview
Loading executive summary…
Click any tile to see the exact findings behind it. Open risks are actionable and not yet resolved; findings are the raw observations before they’re scored into risks; counts reflect unique machines, not sensor check-ins. Every score shows its tenant and time range on hover.
Security posture
Risks by severity
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 |
|---|
Every cloud data store — object storage, databases, secret stores — and the AI agents and workload identities that can reach each one, joined from the cloud graph. This is permission-permits-access reachability, so you can cut off a path before it is ever used; the observed-use half (which sessions actually read a store) arrives with runtime telemetry.
| Severity | Data store | Type | Provider | AI reachers | Paths | Exposure | Owner |
|---|
Every AI system in use, derived from discovery, classified for conformity — the EU AI Act risk tier, whether you're the provider or deployer, the accountable owner and its lifecycle. This bridges what the sensors discover to what your governance program must account for. The tier is your recorded classification, not an automated legal determination.
| Risk tier | AI system | Footprint | Role | Owner | Lifecycle |
|---|
Model a proposed change on the current cloud graph and see its blast radius before you make it — widen a workload's data access, or make a data store public. It's a deterministic reachability forecast, not a claim that the path is exploitable.
Execution traces reconstruct a single AI interaction end to end — user → prompt → retrieval → model → agent → tool → resource → outcome — so a SOC or IR analyst can investigate an incident, not just read a config log. This is observe mode: it shows what happened; live response actions (terminate a session, revoke an agent token) need an enforcement point and are on the roadmap.
| When | Operation | User | Models | Tools / data | Spans | Status |
|---|
Your AI apps emit spans to POST /api/v1/traces (OpenTelemetry-GenAI shaped) using a service API key with the write:traces scope. Once instrumented, each AI interaction appears here as an investigable timeline.
Per code location, the AI-specific issues a pre-merge / release gate should catch — hardcoded AI secrets, vulnerable or unpinned AI dependencies, untrusted MCP/skill provenance, and AI-authored code pending review — and the resulting pass / warn / block verdict. Wire it into your pipeline via the API to fail a merge on a blocking issue.
| Gate | Location | Secrets | Vuln deps | Unpinned | Untrusted | AI code |
|---|
Gate rules — policy as code
A curated library of adversarial test packs — prompt injection, jailbreak, sensitive-info disclosure, insecure output, excessive agency — aligned to the OWASP LLM Top 10 and MITRE ATLAS. Run them against an authorized target model or agent, and track pass/fail and regression as models, prompts, tools and policies change.
Test-pack catalog
Run history — for regression
Every AI library, MCP server and agent skill on your fleet — de-duplicated — with a trust verdict from real signals (a known CVE, an unpinned version, an untrusted source) and a fleet-wide approve / quarantine decision. This turns your AIBOM from an inventory into a release gate. The verdict is provenance + pinning + known-CVE — not a deep binary scan; unverified means not-yet-reviewed, never “proven safe”.
| Verdict | Component | Version | Kind | Hosts | Governance |
|---|
Triaged risks aren’t deleted — they move to their status. Actionable is the working queue: Open + Acknowledged only. Accepted, resolved, muted and false-positive risks are triaged out — pick a status to find them, then reopen any 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.
Attack chains — how individually small or medium findings chain into full compromise: foothold → execution → credential access → privilege escalation → lateral movement → cloud/domain escalation → impact. Reasoned from observed evidence, never exploited. A chain that reaches Impact is Critical even when every input is only Medium — the executive view of why "a few mediums" is a breach path.
How this relates to the Capability graph: a capability path is an observed access relationship on one host (device → agent → MCP → credential → egress); an attack chain is the ATT&CK stage sequence that can form from those and other signals and may span hosts — so the two counts differ by design. Each chain shows which stages are observed vs inferred, and the control that breaks it.
AI Bill of Materials — the per-host inventory of AI assets across your fleet, with a threat assessment of which components are known-vulnerable. Vulnerabilities are matched from live threat intelligence (CISA KEV · NVD · OSV) against the exact installed package and version — not guessed.
| Package | Ecosystem | Versions | On machines | Status |
|---|
| Priority | Action | Advisories | Hosts |
|---|
All matched advisories — per host / per CVE (the underlying detail)
| CVSS base | Package | Version | Context (advisory) | Host | Advisory |
|---|
AI Cloud Security Posture — an agentless assessment of your cloud account's AI attack surface (who can invoke Bedrock/SageMaker, exposed model endpoints, public training/RAG data, over-privileged agent-assumable roles, IMDSv1 → credential theft). This is separate from the endpoint sensor; it reads the cloud config via a read-only role.
demo| Severity base→AI-adjusted | Finding | Service | Resource | Account · Region | Framework |
|---|
| Severity | Control | Resource | Evidence |
|---|
| Provider | Resource | Type | Account / region | Owner / environment | Last observed |
|---|
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 | Reach | Lifecycle | 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 tool or model (e.g. DeepSeek) and it is flagged as blocked fleet-wide and alerted on. Note: the endpoint sensor is observe-only — it flags and alerts but does not block in-line on the host; actual in-line enforcement needs an enforcement point (egress proxy / browser extension) and is on the roadmap (see Governance).
Approved AI tools — one per line or comma-separated
Blocked tools / models — names
Blocked domains — egress hostnames
The endpoint sensor is observe-only — it does not block or modify the host. “Enforce intent” raises a denied tool to a policy violation and alerts on it; actual in-line blocking (null-route / process-kill) requires an enforcement point (egress proxy / browser extension) and is on the roadmap. Leave off to observe-and-report only.
AI-DLP — content policy engine — decide block / redact / warn per data class
The DLP inspection API classifies content — secrets, PII, PCI, PHI, source code — and returns a per-class decision that your enforcement point (browser extension / egress proxy) applies. Monitor logs & warns only — safe to start; Enforce returns block/redact decisions. Set the policy per tenant, and stricter per crown-jewel machine from a device's detail. Inline in-browser blocking is on the roadmap; 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.
The report PDF is encrypted; share this password with recipients out-of-band.
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 |
|---|
Loading…
Loading…
Loading…
Loading…
Loading…
People ranked by AI-risk exposure. Enrich with your IdP to add name, department, and employment status.
| Person | Department | Status | Devices | Open risks | Posture |
|---|
| Provider | Fingerprint | Masked | On machines | Status |
|---|
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 Araghatta 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.