Compliance status
We publish our real status rather than badges we haven't earned. Where a certification is not yet complete, we say so — and we can share our current controls, policies and evidence under NDA today.
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type I | In progress | Controls implemented; readiness assessment underway — Type I attestation targeted Q1 2027. |
| SOC 2 Type II | Planned | Observation period to follow Type I. |
| ISO/IEC 27001 | Roadmap | ISMS controls mapped; certification targeted next. |
| ISO/IEC 42001 (AI management) | Aligned | Our own product maps findings to 42001; internal alignment underway. |
| GDPR | Aligned | DPA available; data-subject request process in place. See Privacy. |
| EU AI Act | Mapped | Findings map to Art. 9 / 15 / 55 obligations; we deliver the evidence structure. |
What the sensor collects — and what it never does
What it collects
Metadata of AI usage: process/binary names, MCP config locations, API-key presence and provider (never the value), installed AI CLIs/SDKs, browser-extension IDs, and egress destinations to known AI endpoints — attributed to machine and user.
What it never collects
Not the contents of your files, not secret values (masked at the point of collection), not keystrokes, not prompt/response bodies, not personal browsing. Command lines are scrubbed of secret-shaped tokens before they leave the endpoint.
Architecture & data residency
- Sensor is read-only. It observes and reports. It does not modify files, kill processes, or change security settings.
- Enforcement is a separate, explicitly-authorised channel. Response runs through a distinct policy-and-response path an operator opts into — the content-DLP policy engine and remote-pause today, with host/agent enforcement on the roadmap — never the sensor by itself. This is the boundary architects ask about, stated plainly.
- Deployment options. Managed (our AWS, single-tenant isolation) or fully in-VPC — the console and the classification model run inside your AWS account with no data egress. In-VPC uses Amazon Bedrock for reasoning so prompts never leave your boundary.
- Data residency. Managed tenants can be pinned to a region (US or EU). In-VPC keeps 100% of data in your account.
Encryption, access & keys
- In transit: TLS 1.2+ everywhere; HSTS; sensor-to-console is mutually authenticated with a per-device enrollment secret.
- At rest: encrypted storage; secrets held in AWS SSM SecureString / your KMS.
- Access control: role-based access across four roles — Viewer / Analyst / Admin / Owner (plus a Platform Admin role for Araghatta staff) and custom roles — TOTP MFA on every account, and a tamper-evident audit trail on every action. SSO (OIDC) and SCIM 2.0 are live (Enterprise tier); SAML 2.0 is on the roadmap.
- Integration secrets (Slack webhooks, Jira tokens) you enter are encrypted at rest and never returned to the browser.
Subprocessors
We keep this list short and current. Managed deployments use:
| Subprocessor | Purpose | Region |
|---|---|---|
| Amazon Web Services | Hosting, storage, secrets (KMS/SSM) | US / EU (per tenant) |
| Amazon SES | Transactional email (enquiries, alerts) | US |
| Reasoning backend (configurable) | AI triage — hosted API, or Amazon Bedrock in-VPC, or fully local | Per configuration |
In-VPC deployments have zero external subprocessors for data processing. See the canonical, dated sub-processor list; a signed version is part of the DPA.
Vulnerability disclosure & incident response
- Report a vulnerability: info@araghatta.com. We acknowledge within 2 business days and coordinate disclosure in good faith.
- Incident response: defined runbook; customer notification for confirmed incidents affecting your data within 72 hours, with a root-cause summary to follow.
- Product security: the sensor binary is versioned and signed; updates are pinned by version and verified before rollout.