Security & Trust
The safest place for your AI-risk data is the endpoint it came from.
Sargha is engineered so the material most dangerous to mishandle (secret values) is never collected in usable form and never transmitted. Everything else is metadata, encrypted end to end, and isolated per customer.
- SOC 2 (in progress)
- ISO/IEC 27001 (in progress)
- CSA STAR (in progress)
- GDPR DPA available
In progress, and stated as such.
None of the three is complete, so none is claimed. A signable GDPR DPA is available now. Our current controls, policies and evidence are shared under NDA. See the Trust Center for status and the security package.
Six properties hold true on every endpoint.
Six properties hold true on every endpoint, on every platform, out of the box.
Secrets never leave the host
Secrets are never collected: API keys are masked at the point of collection, and we never see the usable key.
Redacted at the source
Command lines are scrubbed of tokens and passwords on the endpoint, before anything is sent.
Encrypted in transit
Encrypted to the collector, with each sensor authenticated to your tenant.
Encrypted at rest
Findings are stored in an encrypted database; platform secrets are held in managed, key-protected storage.
Isolated per customer
Each customer is logically isolated by default; a physically dedicated tenant is a custom project. Every customer has its own organization, users, keys and configuration, and its own audit trail. Isolation is enforced in the database and in the application. A customer-cloud (in-VPC) deployment is available by arrangement.
Read-only by default
Discovery is read-only: the sensor inspects, and never edits files, installs software, or changes security settings. Enforcement is opt-in and audited. Privileges and the command path come with the demo and technical pack.
What we collect, and what we never touch.
Detection needs metadata, not your data. The sensor draws a hard line between the two.
Metadata only
- AI tools, agent CLIs and SDKs in use
- MCP / agent configurations and their servers
- API-key locations with a masked prefix and length
- Connections to known AI provider domains
- Device context: hostname, OS, user, IP
Never collected
- API key values, passwords or tokens
- File contents or documents
- Browsing history, cookies or page content
- Keystrokes, screenshots or the clipboard
- Full packet capture of your traffic
Encrypted end to end, isolated per customer.
In transit
Encrypted in transit. Sensors authenticate to your tenant, and the application is never exposed directly.
At rest
Findings are stored in an encrypted database. Platform secrets live in managed, key-protected storage. Administrative access is brokered.
Isolated at every layer
Tenants are isolated in depth, in the database and in the application, and each sensor is bound to its tenant. Findings are encrypted at rest in the United States (AWS us-east-1) for managed tenants. For regulated fleets, a physically dedicated tenant is a custom project and an in-VPC deployment is available by arrangement; with in-VPC, your data stays in your AWS account. Roadmap Customer-managed keys and Roadmap regional data planes on managed tenants are planned.
One binary per platform, pushed by your MDM.
Nothing manual on the endpoint.
The sensor runs as a supervised service that restarts on crash and starts on boot. If the network drops it keeps scanning and catches up when the collector is reachable again. Events are kept on disk during an outage and sent in order. Full steps come with the Deployment Guide in the demo and technical pack.
How the controls map to what your auditors ask about.
| Control | How it is met |
|---|---|
| Data minimization | Metadata only; secret values masked and command lines redacted at source. |
| Encryption in transit | Encrypted between sensor and console. |
| Encryption at rest | Encrypted database; key-protected storage for secrets. |
| Access control | Role-based access with ranked roles; TOTP multi-factor authentication. |
| Auditability | Per-tenant application audit log of security-relevant actions, exportable as CSV or JSON. Each entry is chained to the one before it with a hash, and a signed checkpoint is taken every six hours, so a changed or removed entry is detected. Entries from before the chain was switched on are not covered. |
| Tenant separation | Each customer is logically isolated by default (own organization, users, keys, configuration and audit trail), in the database and the application. A physically dedicated tenant is a custom project; a customer-cloud (in-VPC) deployment is available by arrangement. |
Built for AI governance, not employee surveillance.
A sensor on every endpoint has to earn the trust of the workforce, not just the security team. Ours is built for AI governance, not employee surveillance.
Metadata, not content
The sensor records that an AI tool is in use and never reads file contents, prompts and responses, keystrokes, screenshots or the clipboard. Secret values are masked at source. The optional in-browser DLP extension checks submitted text in memory and does not store it.
DPIA-ready data map
A clear map of what is collected, why, and the lawful basis: the exact input a Data Protection Impact Assessment needs.
Works-council support
Where employee-monitoring rules require consultation (e.g. an EU works council / Betriebsrat), we provide documentation to support it before rollout.
Least data, role-scoped
Access to findings is role-based, so you can scope who sees attribution. Retention is configurable per tenant (findings and audit, 30-day minimum) and applied automatically; by default data is kept until deleted, and is export-then-deleted on request. Optional pseudonymization (off by default) stores tokens instead of machine, account and cloud resource names.
How the sensor is constrained.
Putting any agent on every endpoint is a risk decision. Here is how ours is constrained. The full detail comes with the demo and technical pack.
Commands: a defined, audited path
Pause, revoke and, when switched on, enforcement actions are operator-authorized, role-gated and audited. The sensor only calls out and opens no port reachable from the network. While endpoint blocking is on, macOS and Windows machines keep one socket bound to the machine’s own loopback address, used only to block the sub-domains of blocked sites; Linux opens none.
Read-only by construction
Discovery is read-only: it inspects, and never edits files, installs software, or changes settings. Enforcement is available as an opt-in, audited mode (warn, then block or quarantine, operator-authorized and logged), alongside the content-DLP policy engine, remote-pause, and hard device revocation (a stolen or rogue device is cut off server-side and can’t re-enroll).
Privileges, stated plainly
The sensor runs with elevated rights because it must read other users’ files. Enforcement actions are opt-in and need elevation too. The per-system detail comes with the demo and technical pack.
Pinned, verified updates & attestation
Updates are signed and pinned, and a sensor only applies an update that verifies (downgrades are refused). The platform also checks that each sensor is an official, unmodified build; anything else is flagged, and the device can be paused or revoked server-side through the operator-authorized response path.
Tamper-resistant, admin-only uninstall
It runs as a system service a standard (non-admin) user can’t stop or uninstall. Removal is a single admin/MDM action: the binary and its small identity file are deleted; nothing else on the machine is touched.
Audit it first
Before deployment we walk you through exactly what the agent collects and does. Full data-handling detail is in the FAQ.
Fewer moving parts.
Single static binary
The sensor ships as one self-contained program per OS: no interpreter or dependencies to install. Fewer moving parts, a smaller supply-chain surface.
Provenance on request
Every release is built by a scripted, versioned pipeline and stored immutably under its own version, with checksums you can verify, so you know exactly what you are deploying. Windows builds and macOS builds are code-signed (macOS: Apple Developer ID, notarized) and Linux builds carry a detached signature. Each release also ships a signed software bill of materials.
We treat researchers as partners, not adversaries.
We welcome reports from security researchers and treat them as partners, not adversaries.
How to report
Email info@araghatta.com (also in security.txt). Dedicated security address: not published yet; until then use info@araghatta.com PGP: no PGP key is published yet We acknowledge within 2 business days, keep you updated, and coordinate disclosure in good faith. In scope: araghatta.com, its subdomains, and the sensor.
Safe harbor
If you make a good-faith effort to comply with this policy, we will not pursue or support legal action against you for your research. Please avoid privacy violations, data destruction and service degradation, and give us reasonable time to remediate before public disclosure.
Service and incident commitments.
What we state today, and the contracted target for each commitment.
| Commitment | What this site states today | Contracted target |
|---|---|---|
| Breach notification | Customers are notified of a confirmed personal-data breach affecting their data without undue delay and within 72 hours of confirmation (DPA), with a root-cause summary to follow. | without undue delay and within 72 hours of confirmation, with a root-cause summary to follow |
| Uptime | Uptime and SLA terms for Discover + Warn and Discover + Warn + Block are set in the order form. | target 99.9% monthly availability for the managed service, not yet independently measured; the contracted commitment is in the order form |
| Recovery (RPO and RTO) | Encrypted database backups with point-in-time recovery; restore drills are planned. | database: Multi-AZ PostgreSQL with point-in-time recovery to within about five minutes and 7-day backup retention (RPO about five minutes). No RTO figure is published yet; recovery objectives are agreed per tier in the order form |
| Incident response times | Defined incident runbook. Vulnerability reports are acknowledged within 2 business days. | severity-based response targets are set per plan in the order form, with 24x7 handling of Severity 1 incidents on the Premier support plan; confirmed incidents affecting your data are notified within 72 hours |
Security documents, with the technical pack.
We’ll share the full whitepaper and the Deployment Guide.
The complete, control-by-control detail your security team needs, including recommended hardening options.
See the AI on your fleet in about a week.
Run the sensor across your estate and receive an AI risk report and an AI Bill of Materials. The assessment is free and carries no commitment.