Legal
Privacy notice (draft)
How Singularity AIDR handles personal data on this website and in the hosted dashboard, in plain language.
Singularity Research & Development · Effective date: TBD
What this covers
This draft covers the public website and the hosted web dashboard operated by Singularity Research & Development. The AIDR software that runs on a developer machine is described separately below, because most of what it does stays on that machine.
Roles: for dashboard records about your agents and your users, your organization decides what is collected and we process it on your behalf (see the DPA summary). For website visits, sign-up and enquiries, we decide why and how data is used.
Data we handle on the website and dashboard
| Category | Examples | Purpose | When |
|---|---|---|---|
| Account and sign-in | Email address, name, profile image, sign-in method, session identifiers (held by Clerk). | Create and secure your account and sign you in. | When you sign in or create an account. |
| Dashboard records | Registered agents and installation identifiers, policy documents, security events and incidents reported by your enrolled agents, audit entries, plan and seat information. | Provide the dashboard, policy rollout, incident review and billing entitlements. | When you use the dashboard or an enrolled agent reports to the control plane. |
| Contact and evaluation requests | Name, work email, company, topic and message; the use case you describe in an evaluation application. | Reply to you and decide whether to approve an evaluation. | When you submit the contact form, the waitlist or the evaluation application. |
| Billing | Billing contact, plan and seat count. Card and tax details are entered at Polar and are not stored here. | Process orders placed through hosted checkout. | Only if you place an order through hosted checkout. |
| Technical request data | IP address, user agent, requested URL and timestamps, kept in hosting and application logs. | Operate, secure and debug the website; rate-limit abuse. | Every request. |
| Optional error diagnostics | Error messages, stack traces and technical context sent to Sentry. Session replay is not enabled. | Find and fix defects. | Server-side when a Sentry project is configured. In your browser only if you choose Allow diagnostics. |
We do not sell personal data. We do not run advertising or analytics trackers on this website.
What the AIDR software does with data
Detection and policy decisions run on the developer machine. Local detection does not upload source files or full prompts. Some features have their own outbound paths, and each one is controlled by configuration:
- URL, file and package reputation: when enabled, extracted URLs, package names and versions, and file hashes (SHA-256) are sent to the configured reputation service. File contents are not uploaded by these checks. In source defaults these checks are off, and they need a deployed first-party endpoint to work.
- Managed control plane: only when an installation is enrolled and sync is turned on. Events pass through a credential scrub, and by default tool summaries and artifacts are replaced by hashes. Other modes can keep ordinary command or URL text, so the setting should be reviewed for sensitive environments.
- Version check: off by default. When on, it sends versions, operating system and a random installation identifier.
- Deep scans and alerts: only when an operator configures a scan bridge or a webhook. These can contain full targets or file paths, so the destination should be one you control.
Local audit logs can contain security evidence. Keep them confidential and review them before sharing in a support ticket.
Retention
Final retention periods are one of the items awaiting legal and privacy review. The periods below are the ones the service stamps on records today; they are not a contractual commitment.
- Device codes (15 minutes), install codes (15 minutes) and enrollment tokens (30 minutes) are short-lived.
- Only a digest of a device code or enrollment token is stored, never the credential itself.
- Event records are stamped to expire after 365 days for blocked or critical events, 180 days for warnings and requests held for approval, and 90 days for the rest. Each event keeps an allow-listed set of fields, with credential-looking strings redacted.
- Control-plane audit entries are stamped to expire after 90 days.
- Expired records are removed by database time-to-live policies defined in the repository. They take effect once the operator deploys them to the database, and removal can lag expiry by up to a day or so.
- Other dashboard records are kept while the account is active. A deletion schedule is to be defined.
Your choices and rights
You can ask us to access, correct, export or delete your personal data, or to object to or restrict its use, depending on where you live. Requests are handled by a person and there is no automated self-service flow yet. Send a request through the privacy contact. A response deadline has not been approved.
Where data is processed
The regions used by our providers have not been confirmed, so no residency or transfer commitment is made yet. EU, US and Asia-Pacific placement is an intended option that is not yet available.
Security
See the security page for how the product and this site are protected and for what has not yet been independently verified. No system is perfectly secure.
Changes and contact
This draft will be replaced by an approved version. The effective date is shown at the top once it is set. Questions: privacy contact.