Overview
Tick rows in the table to scope this to specific sensors or issues — otherwise it covers everything the current filters show.
ⓘ About this page
Your AI supply chain in one place: every third-party component your AI touches — packages & libraries (with versions), MCP servers, skills, RAG apps and vector stores — deduplicated across the runtime stack and the AIBOM. Each row shows its versions, where it runs, its provenance (trusted / unverified / typosquatted), and any known vulnerabilities. RAG apps, Vector DBs, Skills and MCP are type filters over this one list. Click a component for its single canonical record.
How this differs from Threat intelligence: this page is your inventory of what your AI is made of. Threat intelligence asks a different question, which known attacks and vulnerabilities match what you run, so one component can appear on both pages for different reasons.
| Component | Type | Ecosystem | Version(s) | Hosts | Provenance | Known vulns | Risk |
|---|
Loading executive summary…
Risk breakdown & trend
Exposure pipeline
Risks by severity
By category
Status answers “is this AI approved?”: Flagged not approved · Pending not yet triaged · Sanctioned approved by policy · Clear benign. Risk answers “how serious is it?” and is separate — an approved provider whose API key is exposed is Sanctioned but keeps its High risk until the key is rotated or removed.
| Risk | Machine | Category | Name | Detail | Status | Seen | Source | Feedback |
|---|
ⓘ About this page
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 | Access | Paths | Exposure | Owner |
|---|
| Status | Method | Path | Service | Calls | Last seen | Hosts |
|---|
ⓘ About this page
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 |
|---|
ⓘ About this page
Model a change on the current cloud graph in two directions: assess a risky change (does it add exposure? — get an allow/warn/block gate), or preview a mitigating control and watch the risk drop before you decide to apply it. A deterministic reachability forecast, not a claim the path is exploitable.
ⓘ What is the AI runtime stack?
ⓘ How discovery works (and why the unknown is caught)
Deploy a sensor to a host running AI applications — RAG apps, vector databases, agents and model servers appear here as they're discovered.
Your RAG apps, vector databases, agents and model artifacts appear here once a host running AI is reported. The on-host collector that gathers these signals is rolling out — deploy it to a host running AI applications, and this view populates automatically. Read: The AI runtime stack →
ⓘ About
ⓘ How this relates to your identity provider and cloud IAM
This page adds what those systems do not cover: a separate identity for each AI agent, with a named human sponsor, and a gateway that decides allow, deny or escalate before an agent touches data. Sargha does not create accounts in your identity provider or roles in your cloud. Credentials issued here are Sargha's own and do not replace your IAM.
ⓘ How to try it
1 Agent identity fabric Initiative 4
ⓘ How it works
An autonomous agent is only as trustworthy as its identity. Most agents today act under a shared service principal, or under a name a hostile caller can simply claim — the classic confused-deputy problem. The fabric issues each agent a short-lived, cryptographically verifiable credential bound to a named human sponsor, so the gateway can tell a proven identity from a merely asserted one.
2 Authorization gateway Initiative 3
ⓘ How it decides
Detection reports after the fact. The gateway decides before an action runs: an agent, MCP layer or SDK asks, and receives allow / deny / escalate. The decision is deterministic and computed entirely from your tenant-side policy, governance and observed evidence — it never consults a model and never trusts the agent's own claims, so a prompt-injected agent cannot reason past it.
- Identity & lifecycle. A retired identity is denied; an unverified identity may not take a sensitive or state-changing action.
- Approved-AI policy. A tool on your denylist is denied outright.
- Sensitivity vs. ownership. Writing to restricted or confidential data requires a verified, owned identity — and still escalates to a human.
- Irreversibility. Payments and other irreversible actions always escalate.
- Attack-path membership. An agent sitting on a live attack path carries extra scrutiny.
- Business criticality. Actions against business-critical systems escalate.
Safe to adopt. Whether a deny is actually enforced is governed by your enforcement mode — run in observe first (every decision logged, nothing blocked), tighten to enforce when ready.
3 AI risk quantification Initiative 7 · v1
ⓘ What this is
ⓘ About this page
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.
| 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.
ⓘ About this page
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 | User | Secrets | Vuln deps | Unpinned | Untrusted | AI code |
|---|
Where the issues concentrate — by host user
Gate rules — policy as code
Setup — authorized target & runners not configuredconfigure ▾
Target endpoint not configured
Point the packs at an OpenAI-compatible chat endpoint you own and are authorized to test — OpenAI, Azure OpenAI, or any /chat/completions-compatible gateway (vLLM, Ollama, LiteLLM, OpenRouter…). The hosted scanner reaches public https endpoints only; the API key is encrypted at rest and never shown again.
Self-hosted runners private / on-prem
For private or on-prem endpoints, run a small runner in your own environment. It connects out to Sargha (no inbound ports), pulls jobs, tests your internal target locally, and posts results back — so probes hit your endpoint from inside your network, not from Sargha.
Test-pack catalog — every probe, by OWASP category
Run history — regression across runs
ⓘ About this page
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 |
|---|
Read-only to the platform — it only sends HTTP to the selected agent, SSRF-guarded to loopback/private endpoints, with benign canary/tool probes mapped to OWASP LLM Top 10 & MITRE ATLAS. Credentials are used only to reach the agent and are never stored or shown back.
Attack paths are inferred — reasoned reachability over observed edges. Here you prove them: open any attack path (Cloud attack paths, Attack graph, MCP) and click ⚡ Validate reachability to actively probe each hop — live IAM policy simulation, network/TLS reachability, MCP handshakes — read-only, nothing exfiltrated or changed. A path that can't be reached is re-graded down. Endpoint-local hops are proven by the sensor (opt-in). Every run is recorded below as evidence.
| When | Surface | Path | Result | Reach | Severity | By |
|---|
ⓘ About this page
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.
ⓘ About this page
Your AI risk register. Each risk is assessed for likelihood × impact (inherent score, 1–25), reduced by the controls you record to a residual score, and carries an accountable owner, a treatment, a status workflow (identified → assessed → treatment planned → treating → accepted / closed), evidence and framework references (NIST AI RMF · ISO 42001 · EU AI Act · SOC 2 · ISO 27001). Populate it three ways: Auto-draft from findings (an assessed risk per live engine risk — scored, framework-mapped and auto-populated when you open this tab; idempotent), Import CSV, or + Add risk. Framework references are reviewer guidance, not a certification.
| Ref | Risk | Category | L | I | Inherent | Residual | Owner | Status | Due |
|---|
ⓘ About this page
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.
ⓘ About this page
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 |
|---|
ⓘ About this page
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.
| Severity base→AI-adjusted | Finding | Service | Resource | Account · Region | Framework |
|---|
ⓘ Analysis boundary
ⓘ Re-evaluate and Export evidence — what they do
Re-evaluate re-scores the cloud data Sargha already holds. It does not touch your cloud; a scan is a separate button. The result line above the tiles says how many controls and attack paths were re-scored.
Export evidence downloads a JSON file (a machine-readable format) of resources, failing controls and attack paths with their evidence, so an auditor can check them or a GRC or SIEM tool can ingest them. Each attack path's detail also offers a signed evidence packet you can verify.
| Severity | Control | Resource | Evidence |
|---|
| Provider | Resource | Type | Account / region | Owner / environment | Last observed |
|---|
ⓘ About this page
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.
How this differs from Components & supply chain: that page is the inventory of what your AI is made of. This page is about known threats that match it. Open an item to see where it runs, why it matters, and to raise a ticket or add it to the risk register.
Continuous threat-intel engine
Live exposures — catalog matched to your inventory; threat severity is capability-specific. Click a row for the scoring rationale.
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 |
|---|
| 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.
ⓘ What is MCP, and why it matters
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 |
|---|
ⓘ What are non-human AI identities
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
A scheduled report is a board or auditor report that Sargha emails on its own every week or month, so nobody has to remember to generate it. An administrator sets the schedule, the recipients and an optional PDF password below. If you cannot see the schedule form, ask an administrator. To get a report right now, open Compliance and choose Generate report.
ⓘ About this page
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: by default the sensor observes — it flags and alerts. Real in-line block / quarantine (process kill, egress cut and, for quarantine, network isolation of the machine) is built into every sensor and switches on for a tenant licensed for enforcement — turn it on in Enforcement & exceptions → Enforcement lifecycle.
Approved AI tools — one per line or comma-separated
Download only my approved list (short file, approved items only) · Download the full catalog, remove the # in front of the tools your company allows (or delete lines you don't want), add your own names at the bottom, then upload it back. Changes apply to existing findings straight away.
Blocked tools / models — names
Blocked domains — egress hostnames
By default the sensor observes and does not modify the machine. “Enforce intent” raises a denied tool to a policy violation and alerts on it. Actual in-line blocking (process kill · egress cut) is applied on the machine by the sensor when the tenant sets Enforcement & exceptions → Enforcement lifecycle to block or quarantine (needs the Enforcement licence). Leave off to observe and report only.
Observe / Block groups — set a response mode for a set of hosts or users
Bucket crown-jewel servers, a team’s machines, or specific users into a group and choose how the platform responds to their AI activity. Observe detects only; Warn and Require approval add governance; DLP monitor / enforce apply the server-side content decisions. Endpoint “block” / “quarantine” (process-kill + egress-cut; no network-level host isolation) is real, but gated — it works only for a tenant that is licensed for enforcement and running the enforcement-capable sensor build; the default sensor stays observe-only. “Enforce” here means policy + governance + server-side DLP decisioning + the CI/CD gate + per-device pause/revoke, without touching the host.
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. Blocking inside the browser is done by the Sargha browser extension, which the sensor on each machine configures; switch it on below.
Blocked AI destinations — hostnames; prompts to these are blocked
Legal hold — suspend deletion of data for a legal matter
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 security report on a cadence
Email a security report — 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.
ⓘ About this page
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…
ⓘ About this page
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 |
|---|
ⓘ About this page
Every triage, comment, false-positive, directory sync, and quarantine — who did what, when. The tamper-evident record for auditors.
| When | Actor | Action | Detail |
|---|
ⓘ About this page
Push new AI-risk findings straight into the tools your team already lives in. Each tenant has its own connection — secrets are encrypted at rest and never shared across orgs.
ⓘ About this page
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).
ⓘ How SSO, SCIM and ownership sync fit together (and what Sargha never asks for)
You never give Sargha an identity-provider admin password. Each feature uses its own, narrow credential that you create in your own Okta, Entra or other directory:
- Single sign-on (OIDC or SAML). People sign in to Sargha with your identity provider. You create an app there and paste its issuer and client ID and secret (or its SAML details) here. Your provider handles passwords and MFA. Users are created on first sign-in and mapped to a role by their group.
- SCIM. Your provider pushes users and groups to Sargha so joiners, movers and leavers follow your directory. Sargha shows a bearer token once; you paste it into your provider. It cannot read your directory.
- Ownership auto-sync. Sargha reads your directory to fill in each device's owner and team. It needs a read-only API token you create in Okta, Entra or ServiceNow, and nothing more.
Cloud accounts are connected separately with read-only roles (see Cloud security). Revoking any of these on your side cuts that access immediately.
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. Choose OIDC or SAML 2.0 below.
Configure an OIDC app with redirect URI https://…/auth/sso/callback.
Create a SAML 2.0 app in your IdP and paste its details here. The SP verifies the signed assertion (RSA-SHA256, exclusive-C14N) and enforces audience, validity and recipient.
SP Entity ID / metadata: —
Ownership auto-sync offLiveOkta · Entra · ServiceNow — fill device owners automatically
Pull your people directory from a read-only IdP/CMDB connector and set each enrolled device’s owner and team automatically — no more manual tagging. Matching is by local username / email; runs are idempotent, and you can dry-run first.
Bidirectional EDR / ITSM offLiveCrowdStrike · Defender — coverage cross-check
Read your EDR’s own device inventory and cross-check it against Sargha’s fleet — surface endpoints the EDR reports that Sargha covers, endpoints the EDR sees that Sargha is not on, and endpoints Sargha sees that the EDR is missing. Read-only.
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 |
|---|
▶
Recent inventory changes — what changed on your AI assets
What changed on your AI assets, per machine: a tool, extension or config that was added after the machine's first inventory, one that is removed (a complete sensor snapshot no longer contains it — it stops counting as inventory and its risks close), and one that was modified (e.g. an MCP server's credential or granted scope changed). Data persists across sensor downtime, so a change is never a silent overwrite. Click a row for details and a link to that machine.
| Status | Health | Machine | Sensor ID | OS | IP | User | Enrolled | Last seen | Agent |
|---|
ⓘ About this page
Install the read-only Sargha 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.
Customer 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.
ⓘ About this page
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.
ⓘ About this page
Twice daily we sweep curated feeds (Hacker News, BleepingComputer, Krebs, Project Zero, MSRC, arXiv) for real-world security incidents & attacks (AI and general — what actually happened, not patches), draft a source-grounded article for each, and email you a digest. Nothing publishes until you approve it here.
Pending drafts 0
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
Appearance
Language
Temporary admin access time-limited
Need to change a setting you cannot change today? Ask for Admin access for a short time. An Owner other than you approves it, it ends by itself, and every step is recorded in the audit log.
Sessions
Signing out everywhere invalidates every other browser or device you're logged in on. This session stays active.
Change password
Two-factor authentication
Passkeys passwordless
Sign in with your device (Face ID, Touch ID, Windows Hello or a security key) — no password to type. A passkey is phishing-resistant and counts as two-factor on its own. Your password stays as a backup.