Privacy Policy
Last updated: 2026-07-29
1. Who we are
Component Atlas is operated by David Alexander Allie, an Australian sole trader trading as Component Atlas (ABN 96 327 603 665), based in Victoria, Australia. We are responsible for the personal information described in this policy.
For anything in this policy, write to support@componentatlas.com.
This policy covers the website at componentatlas.com, the web application, the @component-atlas/cli scanner and the MCP server that coding agents connect to.
2. Information about you and your team
Held in our own database. This is the complete list of what an account consists of:
- Your account
- Email address, an optional name, and a bcrypt hash of your password. Accounts created through Google or GitHub have no password and no hash. We also record whether and when you confirmed your email address.
- Social sign-in
- If you sign in with Google or GitHub we store which provider it was and the account identifier that provider gave us — never a password, and no other part of your profile there.
- Your organisation
- Its name, the plan it is on, and the identifier of its customer record at Stripe. Which organisation you belong to, and your role in it (admin, editor or viewer).
- Invitations
- The email address an invitation was sent to, the role it carries, and who sent it. These rows are deleted the moment the invitation is accepted or revoked, so the table only ever holds invitations still outstanding.
- Sessions and email links
- Signing in creates a session; we store a SHA-256 hash of the session token and its expiry, never the token itself. The same is true of the single-use links in verification and password-reset emails.
- IP addresses
- Recorded only for failed sign-in and password-reset attempts, alongside the email address that was tried, so that we can rate-limit brute-force attempts and mail bombing. Nothing else in the product records an IP address, and see section 8 for how briefly these are kept.
- API and agent credentials
- A bcrypt hash of each CLI upload token, its name, and when it was last used. For MCP connections: the connecting application’s registered details, which member of your organisation authorised it, hashes of its tokens, and when it was last used.
We do not hold payment card details at any point — see section 5. We do not buy data about you, we do not sell or rent anything above, and we do not use any of it for advertising.
3. What the scanner uploads
This is the part worth being precise about, because it is a description of your code. The scanner runs on your machine, against your own configuration, and your source files never leave it. What it uploads for each scan is:
- the file paths and names of the components it found, and the paths and line numbers of every place each one is rendered;
- the names and declared types of each component’s props, and which component rendered which;
- the prop values as written in your JSX — the expressions themselves. A string literal in an attribute is therefore stored verbatim. Anything that is not a literal is stored as the kind of expression it was rather than its text, and no runtime value is ever involved;
- the commit the scan belongs to, when it ran, and any grouping rules (names, colours and path patterns) you configure for the project.
It is a structural description of the code rather than the code — but it is not nothing, and a file path or a literal can itself be revealing. Treat it with the care you would give a directory listing of the repository. Anyone in your organisation can read it; nobody outside it can, other than as described in sections 4 and 5.
4. Who at Component Atlas can see it
A small number of named staff addresses have read access to every organisation’s data, for support and for diagnosing faults. The same list receives operational notifications: a new signup, a new or deleted organisation, an accepted invitation, and milestones in a project’s upload count. Those notifications carry account, organisation and project names.
5. Companies that process it for us
We use these services to run the product. Each receives only what its job needs.
- Stripe — payments
- Card details are entered at Stripe and held by Stripe. They never reach our servers and we never store them: all we keep is the identifier of your customer record there, and your plan. Stripe also holds your billing history and any tax details you give it.
- Resend — email
- Your email address and the contents of the message, for confirmation, password-reset and invitation emails. We send no marketing email.
- Sentry — error reports
- When something breaks, a report of the fault. We have switched off every category the Sentry SDK can collect by itself: cookies, request and response headers, request bodies, URL query strings, local variables from the stack trace, and database query parameters. What we do attach on purpose is your user id, your email address and your organisation id, so that a report can be matched to the person who hit it.
- Google and GitHub — optional sign-in
- Contacted only if you choose to sign in with one of them, and then only to confirm who you are.
These providers are based in the United States, so using them means your data is transferred to and processed there. We share only what each one needs, and rely on each provider’s own safeguards for that transfer.
There is no analytics or advertising service in that list, on this website or inside the product: we run none, so nothing here measures you, profiles you or follows you to another site.
We may also disclose data where the law requires it. We would tell you first unless we were forbidden from doing so.
7. Why we are allowed to hold it
Account, organisation and snapshot data is processed to provide the service you asked for. IP addresses on failed sign-in attempts, and error reports, are processed to keep the service secure and working. Nothing is processed for analytics, profiling or marketing.
8. How long it is kept
We keep personal information only as long as we need it for the purpose it was collected, then delete it. In practice:
- the IP addresses on failed sign-in attempts are short-lived, and are pruned automatically as new attempts are recorded, so nothing accumulates;
- sessions last until they expire or you sign out, and are extended as you keep using the product;
- the single-use links in confirmation and password-reset emails expire shortly after they are sent;
- invitations expire if they are not accepted, and are deleted outright on accept or revoke;
- agent access tokens are short-lived, and their refresh tokens are replaced each time they are used;
- snapshots are kept until you delete them or your plan’s history limit displaces them. A project can be set to drop its oldest snapshot automatically once it is full.
Everything else — your account, your organisation and its projects — lasts until it is deleted. Deleting a project deletes its snapshots and upload tokens. Deleting an organisation cancels its subscription, then deletes the organisation, its projects, its snapshots, its memberships, its outstanding invitations and its agent connections. Your billing history stays at Stripe after that, deliberately: it is a financial record, and closing an account is exactly when someone needs it.
9. Your choices
You can change your name and email address, and delete your projects, snapshots and organisation, from inside the product at any time. Deleting your user account is not yet self-service: write to support@componentatlas.com and we will do it. You can also ask us for a copy of the personal information we hold about you, and ask us to correct it, at the same address.
If you think we have mishandled your personal information, tell us first at that address and we will look into it. If our response does not satisfy you, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au.
10. Security
Passwords are stored as bcrypt hashes and CLI upload tokens likewise. Session and email-link tokens are stored as SHA-256 hashes of server-generated random secrets, so a copy of the database does not yield a working credential. Traffic is served over HTTPS. Sign-in and password-reset requests are rate-limited per account and per network address.
We claim no security certification, because we hold none — you will not find SOC 2, ISO 27001 or a compliance badge anywhere on this site. No system is perfectly secure; if you believe you have found a vulnerability, please tell us at support@componentatlas.com before telling anyone else.
11. Changes, and the law that applies
If we change this policy we will update the date at the top, and tell account holders by email where the change is significant.
Our Terms of Service govern your use of the product itself.
This policy is governed by the laws of Victoria, Australia, and by the Privacy Act 1988 (Cth) and the Australian Privacy Principles.