Privacy Policy
Effective 2 September 2026 · Auric 1.3.0-beta.1
In plain English: we collect very little. Mainly your email address, and — if you sign in to the CLI — the basics of your GitHub profile. Your code, your notes and your project state stay on your device; Auric does not upload them. We keep limited account and workspace metadata, session records, and cookieless analytics. We do not sell your data, run advertising, or build behavioural profiles.
Auric is in private beta. This Policy describes what the product does today, at version 1.3.0-beta.1 — not what it may do later. Where a practice is not yet built, this Policy says so rather than describing an intention as though it were a control.
1. Who we are
Auric gives a software project its own persistent intelligence: a durable record of what the project is, what has happened to it, and where the work stands. It runs as a local MCP server and a command-line tool. In this Policy, "Auric", "we" and "us" mean the operator of the Auric service and the auric.cx website.
For data-protection purposes we act as the controller of the personal information described here — we decide what is collected and why. For privacy questions or to exercise a right, write to privacy@auric.cx.
2. Where your data lives
Auric is local-first, and that single design decision explains most of this Policy. The work itself — your repository, your notes, your project state — never leaves your machine. What reaches our servers is the small amount of account and operational data needed to run a beta.
| Location | What it holds | Who can reach it |
|---|---|---|
| Your device | Your project data, your operational state, and anything you send to your own AI tools. | You. None of it is transmitted to Auric. |
| Auric servers | Email address, GitHub profile basics, waitlist and referral records, workspace metadata (repository name and remote URL only — never file contents), session records, analytics events, and any message you send us. | Auric, and the subprocessors listed in section 7, on a need-to-know basis. |
3. What we collect
You give us: your email address, when you join the waitlist, subscribe, or contact us; your GitHub username; and the name, company, role and message on any contact form you submit.
GitHub and WorkOS give us, at sign-in: your GitHub numeric id and username, your email if it is public, your display name, and your avatar URL. Sign-in is optional and only needed for the CLI. Access and refresh tokens are used to read that profile and are not stored.
We collect automatically: browser and device information; a coarse location derived from your connection — country and city only, never a precise position; device type; the referring page and any campaign parameters in the link you arrived on; and product analytics events.
Two collections deserve to be called out rather than buried. First, CLI session records store your full IP address, not a truncated one, because a session audit trail is only useful if it can identify the origin of a session you did not start. Second, our own analytics event log can be keyed to your email address once we know it, so those events are not anonymous to us.
We do not collect your project data or the contents of your repositories; payment or card details, because there is no billing system; or special-category data. Please do not send us sensitive personal information.
4. Why we collect it
To run the Services and keep them available. To authenticate you and secure your account and sessions. To operate the waitlist, the referral mechanism and beta access. To send you service and security messages, and — only if you asked for them — product updates. To answer your support messages. To understand how the product is used so we can improve it. To detect and prevent abuse. And to meet legal obligations.
Where the law requires a legal basis, we rely on: performing our agreement with you (running the Services, authentication, beta access); our legitimate interests (security, abuse prevention, product analytics and service messages); your consent (marketing email); and legal obligation. You can withdraw consent or object to processing based on legitimate interests at any time.
We do not sell personal information, we do not share it for cross-context behavioural advertising, and we do not build behavioural profiles.
5. AI processing
Auric does not send your data to an AI provider. There is no model integration in the product: Auric holds the state of a project so that the tools you already use — your editor, your coding agent — can pick it up. When you prompt a model, that exchange is between you and whichever provider your own tool is configured to use, under that provider's terms, and Auric is not in the path.
We do not use your data to train models, our own or anyone else's. The AI Usage Policy sets out the full position.
6. Cookies, storage and analytics
The public website sets no cookies. Vercel Web Analytics and Speed Insights run on every page and are cookieless and aggregated. Our own event log records the same events server-side so we are not dependent on a third party for our own numbers.
Cookies appear in exactly two places, both strictly necessary: an authentication cookie when an administrator signs in to the internal console, and a challenge token that Cloudflare Turnstile may set when you submit the waitlist form.
The website stores a small amount of data in your browser's local storage: the campaign parameters and referral code you arrived with, so that attribution survives a navigation, and your progress through the waitlist form. That is first-party, is not readable by anyone else, and is not used to track you across other sites. You can clear it at any time through your browser.
PostHog is integrated but off. It forwards events only if an operator sets an API key, and no key means no data leaves for it. If that ever changes in a way that requires consent, we will ask for it before turning it on.
There are no advertising trackers, no third-party tracking pixels, and no cross-site identifiers. The Cookie Policy has the detail.
7. Who else processes your data
We share personal information with the subprocessors below, where the law requires it or to protect someone's safety, and in a business transfer. That list is the whole list.
| Subprocessor | What it does | Status |
|---|---|---|
| Vercel | Application hosting, edge network, and cookieless web analytics | Always in use |
| Supabase | Postgres database for account, waitlist, workspace, and session records | Always in use |
| Sentry | Application error monitoring (diagnostics only; no product analytics) | Only when enabled |
| WorkOS | Authentication (AuthKit) for CLI sign-in, with GitHub as the identity provider | Only at CLI sign-in |
| GitHub | Identity provider, and resolving a GitHub username from the account id | Only at CLI sign-in |
| Resend | Transactional email — confirmation, invitation, and account messages | Always in use |
| Upstash | Redis-backed rate limiting on public endpoints | Always in use |
| Cloudflare | Turnstile bot protection on the waitlist form | Only when enabled |
| PostHog | Product analytics — server-side event forwarding | Only when enabled |
Error monitoring is worth an explicit note. We use Sentry to record application errors, and only when a DSN is configured for the environment — with none set the SDK is never initialised and nothing is transmitted. What it receives is diagnostic: the error, where in the code it happened, and the request context around it. It is not used for product analytics, and personally identifying request data is not attached by default.
Your information may be processed in the United States and elsewhere. For transfers out of the EEA or the UK we rely on Standard Contractual Clauses, the UK Addendum, or an adequacy decision, as applicable.
8. How long we keep it
Where a period is enforced in code, it is stated exactly. Where no automatic expiry exists yet, this table says so instead of implying one.
| Data | Retention |
|---|---|
| Waitlist record | Until you ask us to delete it, or the beta programme closes |
| Invitation | 14 days from issue |
| CLI session | 30 days from issue, or until revoked |
| Account and workspace metadata | For the life of the account |
| Analytics event log | Retained while the beta runs |
| Support and contact messages | Retained while the beta runs |
9. Security
Session tokens are stored only as a hash, so a database disclosure does not yield a usable token. Sessions can be revoked immediately and expire on their own. Public endpoints are rate limited, and the waitlist form is protected against automated abuse.
Traffic is encrypted in transit with TLS, and database connections require it. Encryption at rest is provided by our database host at the infrastructure layer; Auric does not add a separate application-layer encryption scheme, and we would rather say so than let you assume one.
We do not hold SOC 2, ISO 27001, or any comparable certification, and we have not commissioned a third-party penetration test. The Security Policy describes what we do run.
10. If something goes wrong
If we confirm a breach of personal data, we will contain it, assess it, and notify you and the relevant supervisory authority where the law requires. In the EEA and the UK that means notifying the authority within 72 hours of becoming aware, and notifying you directly where the risk to you is high.
11. Your rights
Depending on where you live, you may have the right to access your data, correct it, delete it, take a copy elsewhere, object to or restrict how we use it, withdraw consent, and not be treated differently for exercising any of these.
We do not make decisions about you by solely automated means that have legal or similarly significant effects, and we do not profile you for that purpose.
These requests are handled by a person, by email: there is no self-serve export or delete button yet, and we would rather tell you that than let you go looking for one. Write to privacy@auric.cx and we will respond within the period the law allows. We may need to verify your identity first.
In the EEA and the UK you can also complain to your supervisory authority — in the UK, the Information Commissioner's Office. In California you have the rights to know, access, correct and delete, and to opt out of the sale or sharing of your personal information; we do neither, and we honour Global Privacy Control signals.
12. Deleting your data
Email privacy@auric.cx and tell us what you want removed. Deleting your account removes your account record, your workspace metadata and your sessions. Removing your waitlist entry removes the email address, the referral record and the attribution attached to it.
Two honest limits. Anything already sent in an email cannot be recalled, and records we are required to keep for legal or security reasons are kept for as long as that requirement lasts. Data on your own device is yours and is not ours to delete.
13. Children
Auric is a professional developer tool. It is not directed to children, we do not knowingly collect their data, and you must be old enough to enter a binding contract where you live in order to use it. If you believe a child has given us personal information, write to privacy@auric.cx and we will delete it.
14. Changes and contact
If this Policy changes materially we will update the effective date at the top of this page and, where the change affects you meaningfully, tell you by email before it takes effect.
Privacy and data-rights requests: privacy@auric.cx. General enquiries: hello@auric.cx. Security reports: security@auric.cx — and please read the Responsible Disclosure Policy first.
Document control
| Field | Value |
|---|---|
| Document ID | AUR-LEG-002 |
| Applies to | Auric 1.3.0-beta.1 — private beta |
| Owner | Auric |
| Review frequency | Quarterly during beta, or on material change |
| Related documents | Terms (001), Cookie (003), Acceptable Use (004), AI Usage (005), Security (006), Disclosure (007), Beta (008) |
| Grounded in | db/schema/workspaces.ts stores name, slug, repo_remote, repo_name — no file contents |
Change log
2 September 2026: The beta is described as private throughout, which is how access is actually granted — requested, confirmed, then opened in waves. No right, obligation, party or data practice changed. Section 1 also describes the product in the terms the rest of the site uses.
1.3.0-beta.1 (2026-08-02): Published for the private beta. Review markers resolved against the implementation, unsupported AI-provider claims removed, and retention stated from the constants that enforce it.