Common questions

By default, yes: the sensor only observes and reports. It opens no port reachable from the network and only makes outbound HTTPS calls to the collector. It does not edit your files or install software. Block and quarantine are built into every sensor and switch on for your organization only with the Enforcement licence and your opt-in. Then the sensor changes the machine's firewall rules and hosts file, only for the destinations and programs your policy names. It checks that they took effect, reports what it finds, and puts everything back when you switch it off. A quarantine that would cut the sensor off from its collector is undone at once, and servers, production and unknown machines are never isolated automatically. Every action is operator-authorized and logged. Block and quarantine are generally available on Windows, macOS and Linux. If you switch on browser protection, the sensor also registers a small helper with Chrome and Edge so the extension can read its settings. How console actions reach the sensor, and the privileges it runs with, come with the demo and technical pack. You can review exactly what the agent does before it is ever deployed.

It collects AI-usage metadata only: AI CLIs/SDKs in use, MCP servers and their package/version/provenance, the presence of provider API keys (masked at the point of collection, never the value), and egress destinations. The sensor never reads file contents, secret values, prompts/responses, keystrokes, screenshots, or the clipboard. Command lines are scrubbed of tokens on the endpoint before anything is sent. The optional in-browser DLP extension, if you turn it on, checks submitted text in memory and does not store it.

One self-contained program per OS, with no runtime or dependencies. It is built to stay out of the way and slows itself down if it ever uses more than a small share of one core. We measured it on one Mac and one Linux VM; Windows and bare-metal Linux are not yet measured. The details are on the sensor page.

Outbound secure connections to your collector only, and the sensor opens no port reachable from the network. The full list of destinations, proxy and pinning options comes with the demo and technical pack.

Windows, macOS and Linux, from one binary per OS. Live tracing of programs and connections runs on Linux; macOS and Windows use scheduled collection of the same surfaces. The portable collectors (AI CLIs, keys, MCP configs, apps, extensions, SDKs, skills, network egress) run on all three.

Push the sensor binary through your existing MDM/config management (Jamf, Intune, Kandji, or Ansible/SCCM) as a background service. No user interaction, no reboot. Deployment kits and guides for Kandji, Ansible and Configuration Manager are written. Roadmap They are in validation on live tools. A typical first scan returns findings in under 15 minutes.

Removal is a single device-management action that stops the service and removes the program, and it touches no other software on the machine. Updates are versioned and pinned, so a specific version can be rolled back through your MDM or your tenant’s update policy.

The sensor opens no port reachable from the network and reports masked findings over TLS to your tenant’s collector (hosted by us in AWS us-east-1, or in your own AWS account for in-VPC). For regulated or zero-egress environments, the platform can run in your own AWS account (in-VPC): your data stays in your account, and reasoning runs on Amazon Bedrock in that account or on local inference. Managed tenants default to OpenAI (United States) for reasoning, and deterministic-only mode sends nothing. Fully air-gapped deployment is scoped per contract; ask us. Roadmap A documented air-gapped package is planned.

Findings are risk-scored by a deterministic engine: inventory (an app on disk) is banded separately from active risk (a live key or a running agent), so you act on what matters, not a flat wall of MEDIUM. An optional AI reasoning layer adds advisory context and triages ambiguous cases; it never changes the deterministic score.

Your EDR hunts malware and your CNAPP checks cloud posture; neither inventories the AI your people actually adopted on their laptops. We build a live AI Bill of Materials (agents, SDKs, MCP servers, keys, egress) attributed to a machine and a person, and map it to the EU AI Act, NIST AI RMF and ISO 42001. We run alongside your EDR/CNAPP, not instead of them: more on that here.

Priced per endpoint per month on a one-year contract, billed annually, with volume tiers. An endpoint is any managed device running the sensor: laptop, desktop, server or VM. Each edition has an annual platform minimum. Start with a free assessment of up to 25 endpoints. See pricing or book a scoping call.

The sensor is built for AI governance, not employee surveillance. It collects AI-usage metadata only (it never reads file contents, prompts and responses, keystrokes, screenshots or the clipboard), so it shows that an unsanctioned AI tool is in use, and on which machine and account, not what anyone typed, unless you turn on the optional in-browser DLP extension, which checks submitted text in memory and does not store it. That data-minimization is deliberately what a Data Protection Impact Assessment (DPIA) or a works council needs to see. We support role-scoped access, a DPIA-friendly data map (what is collected, why, and the lawful basis), and, where employee-monitoring rules require it, such as an EU works council / Betriebsrat, we provide documentation to support consultation before rollout. Full detail is on the Security page.

Use a connector. Cloud accounts, SaaS, phones, LLM gateways, proxy and DNS logs, network gear, storage, IoT and OT platforms and code each have read-only connectors that feed the same inventory as the sensor. Devices that appear in no source stay unseen, and Sargha lists them as blind spots instead of hiding them. See Non-sensor devices.

72 connectors in 16 families, plus 7 collectors for mobile devices (Intune, Jamf, Workspace ONE, sign-in logs, cloud-app and DNS evidence). The 16 families are cloud accounts, SaaS-embedded AI, identity providers, endpoint security (Defender XDR), LLM gateways, web proxy and DNS logs, firewalls, network devices and NAC, IoT and OT platforms, cloud storage, NAS, data platforms, vector databases, source control and CI/CD, Kubernetes, and generic import. The full list names each one.

No write access. Connectors use read-only credentials that you create and can revoke. They read inventory, configuration and usage metadata, not prompts, file or object contents, or secret values. Every call goes through a guarded client with timeouts and size caps.

Your plan sets which connector families are offered, a platform admin can grant or revoke a single connector, and free add-ons are yours to opt in to. Network, firewall, NAS and IoT/OT connectors read private-network gear, so they stay off until your account team enables them for your tenant. See Plans & connectors.

No, and neither should anyone else. Sargha reports how much of the estate it knows about it can see AI on, in five tiers, and names what stays outside: devices in no inventory, traffic off your network, and what a device does internally. See How coverage is measured.

Not yet. SOC 2, ISO/IEC 27001 and CSA STAR are all in progress and none is complete. Until they are, we share our current controls, policies and evidence under NDA. See the Trust Center or request the security package.

Encrypted with the platform cipher, shown masked after you save them, and never logged or returned by the API. For AWS the connector assumes a read-only role with a generated External ID, so no key is stored. For Azure, Google Cloud and Oracle you can rotate or delete the secret at any time.