The safest place for your AI-risk data is the endpoint it came from.
Araghatta 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.
Trust, by design
Six properties hold true on every endpoint, on every platform, out of the box.
Secrets never leave the host
API keys are masked at the point of collection — we report the provider and a fingerprint, never the usable key.
Redacted at the source
Command lines are scrubbed of tokens and passwords on the endpoint, before anything is spooled or sent.
Encrypted in transit
TLS to the collector with automatic Let’s Encrypt certificates and per-device token authentication.
Encrypted at rest
Findings sit on an encrypted volume; platform secrets are held in AWS KMS-backed secure storage.
Isolated per customer
Every customer runs a dedicated deployment — separate compute, database and domain. Tenants are never co-mingled.
Read-only & least-privilege
The sensor inspects; it never edits files, installs software, or changes security settings.
What we collect — and what we never touch
Detection needs metadata, not your data. The sensor draws a hard line between the two.
Collected — metadata only
- AI tools, agent CLIs and SDKs in use
- MCP / agent configurations and their servers
- API-key locations with a masked fingerprint
- 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
TLS 1.2+ everywhere, with automatically-renewed Let’s Encrypt certificates and HSTS. Sensors authenticate with a unique per-device token; the application is never exposed directly.
At rest
Findings are stored on an encrypted volume. Platform secrets live in a KMS-backed secure parameter store. Administrative access is brokered — there is no SSH into the box.
Isolated at every layer
Tenants are isolated in depth: PostgreSQL row-level security scopes every query to one organisation, a least-privilege application role cannot bypass it, and per-device enrolment tokens bind each sensor to its tenant. Findings are encrypted at rest in your region. For regulated fleets, a single-tenant, fully in-VPC deployment (zero egress) is available on the Enterprise tier — your data never leaves your AWS account.
Deploy at a glance
One signed 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, and spools findings to disk so nothing is lost if the network or machine drops. Full steps are in the Deployment Guide.
Compliance posture
How the controls map to what your auditors ask about.
| Data minimisation | Metadata only; secret values masked and command lines redacted at source. |
| Encryption in transit | TLS with automatically-renewed Let’s Encrypt certificates. |
| Encryption at rest | Encrypted storage volume; KMS-backed secure parameter store for secrets. |
| Access control | Role-based access with ranked roles; TOTP multi-factor authentication. |
| Auditability | Append-only application audit log of security-relevant actions. |
| Tenant separation | Dedicated single-tenant deployment per customer. |
Privacy of the people being monitored
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
It records that an AI tool is in use — never file contents, prompts and responses, keystrokes, screenshots or the clipboard. Secret values are masked at source.
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, and data is export-then-deleted on request.
The read-only sensor — and why it can’t be turned against you
Putting any agent on every endpoint is a risk decision. Here is why ours is a safe one: the discovery sensor is built so it cannot be used to attack the machines it runs on.
No inbound command channel
The sensor makes outbound reports only. There is no remote-execution or inbound control path — nothing to hijack into running code on the endpoint.
Read-only by construction
It inspects; it never edits files, installs software, or changes settings. Response runs through a separate, operator-authorised channel — the content-DLP policy engine, remote-pause, and hard device revocation today (a stolen or rogue device is cut off server-side and can’t re-enroll), with inline enforcement on the roadmap; the sensor cannot act on its own.
Least privilege
It runs with the minimum privileges needed to read process, config and network metadata — no opaque kernel driver you cannot remove.
Pinned, verified updates & attestation
Updates are versioned and pinned; every heartbeat, the collector attests the sensor binary by comparing its hash against the published release binaries — anything that isn’t an official, unmodified build is flagged, and the affected device can be paused or revoked server-side through the operator-authorised 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.
Supply chain & integrity
Single static binary
The sensor ships as one self-contained static binary per OS — no interpreter, no package tree, no post-install scripts. Fewer moving parts, a smaller supply-chain surface.
Provenance on request
Every release is produced by a reproducible build pipeline; we provide the release’s SHA-256 hash and a software bill of materials (SBOM), so you can verify exactly what you are deploying. Authenticode and Apple Developer-ID code-signing and notarization switch on once the signing certificates are procured.
Vulnerability disclosure & safe harbor
We welcome reports from security researchers and treat them as partners, not adversaries.
How to report
Email info@araghatta.com (also in security.txt). 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.
Reviewing us for a rollout?
We’ll share the full Security & Data Handling whitepaper and the Deployment Guide — the complete, control-by-control detail your security team needs, including our hardening roadmap.
Request the security whitepaper