Privacy Policy
How Hooldur collects, uses, and protects personal data - for the people who audit their apps with it, and for anyone whose data is inside an app they connect.
Version 0.1 · Effective 23 August 2026 · Last updated 23 August 2026
This policy explains what personal data Hooldur handles, why, and what you can do about it. It is written to be checked: every factual claim below describes something the product actually does today. Where something is not yet established, this policy says nothing rather than something optimistic.
Contact: [email protected]
1. Who we are
Hooldur is an AI-staffed IT department for apps built with AI tools. Today that means one thing: a free, read-only audit. You connect the GitHub repository of an app you built - and, if you choose, its Supabase project and its domain - our agents read them and produce a graded, plain-English report of what they found, and you can run the audit again once you have fixed things.
This policy is published and maintained by the Hooldur Team. Questions, requests, and complaints go to [email protected], and we answer from there.
2. Whose data this is about
Two kinds of information pass through Hooldur, and your rights run differently for each.
| Data about you | Data inside the app you connect | |
|---|---|---|
| What it is | Your account (name, email address, how you sign in), your sessions, the connections you authorise, your answers to our questions, and operational and security data about your use of the service | The contents of the repository, the metadata of the database, and the public face of the domain you connect - and, with them, whatever personal data happens to be in there: a seed file, a test fixture, a commit message, a comment |
| Who decides how it is used | We do | You do. We read it only to run the audit you asked for, on your instructions |
| How to exercise your rights | Directly with us, at [email protected] | If your data is inside someone else's app, through the person who connected it. Deleting the app or closing their account removes it, and we will point you to the right place if you are not sure |
If you have a Hooldur account, or you are visiting our website, the first column applies to you. Section 3 is written for the second.
3. If your data is inside an app someone else connected
You did not choose Hooldur - the person who built the app did. We do not go looking for personal data in a repository, and we have no tool that reads the rows of a connected database (section 9 explains why that is structural rather than a promise). But a repository is whatever its author committed to it, and if that includes your data, our agents read it as part of the audit and handle it exactly as they handle the rest of the repository: encrypted at rest under a key that belongs to that one audit, used for nothing but the audit, and deleted when the person who connected the app deletes it or closes their account.
Contact that person first for any request about your data; they hold the controls. If you cannot reach them, write to us.
4. What we collect
Account data. Name and email address, and the identity we receive from the provider you sign in with. Our sign-in methods are a one-time link sent by email, GitHub, Google, and Microsoft - we do not store passwords, because we do not use them. A profile picture URL may arrive with a GitHub or Google sign-in; nothing in the product displays it.
Session and security data. The IP address and browser user-agent attached to a session, when the session was created, and rate-limit counters keyed by IP address that protect sign-in and a handful of other endpoints from abuse.
Connections. For GitHub: the installation you grant us and the repository it covers. For Supabase: either the project you authorise and the refresh token that authorisation gives us, or - if you choose the read-only database role instead - the connection string for that role. For your domain: the address, and nothing else. Credentials are encrypted as described in section 9.
What the audit reads. The contents and history of the connected repository; the names, owners and access policies of the tables in the connected database, and its backup, storage and API-exposure settings, through five fixed queries and nothing else; and what your domain shows a visitor - its DNS records, TLS certificate, and HTTP response headers. Your dependency manifest is checked against the public npm advisory database.
What the audit produces. Findings (encrypted), the agents' working transcripts (encrypted), a one-line summary (encrypted), each agent's outcome, a record of every query we ran against your database - the query name and whether it succeeded, never the data - and an accounting row for each model call: token counts, cost, and which host served it, never the prompt or the response.
Your answers to our questions. When a report is ready we ask what you would expect the service to cost and what you would want it to do, and capabilities we have not built yet carry a "Want this" control. Each answer is stored as a category against your organization - no free text.
Website data. Nothing. hooldur.com is a static site with no analytics, no contact form, and no cookies, and nothing that identifies you is recorded by us when you visit it. It is served by Cloudflare Pages, which handles the request the way any web host does; our fonts are served from our own site, not from Google.
5. Why we use it, and on what legal basis
| Purpose | Basis |
|---|---|
| Running the audit you asked for, and showing you the result | Performance of a contract |
| Signing you in and keeping your account yours | Performance of a contract |
| Keeping the service secure and preventing fraud and abuse | Legitimate interests |
| Knowing what each audit costs us | Legitimate interests |
| Learning what to build next, from the answers you give us | Legitimate interests |
| Answering you when you write to us | Legitimate interests |
Where we rely on legitimate interests, we have considered the impact on you. The clearest example is the research question: your answer is stored as a category against an organization, not as anything a person wrote, and that is what makes keeping it proportionate - section 11 says exactly what survives and for how long.
6. AI processing
This is the part of the service most worth understanding, so it gets its own section.
An audit is run by language-model agents. They read the repository with read-only tools, decide what to look at, and reason about what they find - and the material they read, together with their own working notes, is sent to the model in the course of that. So repository contents reach the model host, and so do the database metadata and the domain results described in section 4.
Models are reached through OpenRouter, an inference gateway. The model currently serving our audits is one of DeepSeek's; which model serves is configuration and can change, and the current answer is available on request. Three controls apply, and we state them precisely because the differences matter:
- Who may receive the material is a fixed list. We restrict which hosts may serve our requests to a named allowlist - today Anthropic, OpenAI, DigitalOcean, DeepInfra, and Fireworks - rather than letting the gateway choose freely. A request that none of them can serve fails rather than going anywhere else.
- Routing requires zero data retention and no training. We instruct the gateway not to collect our request data, and to route only to endpoints it classifies as retaining nothing and training on nothing. That is what excludes a model author's own endpoint where it trains on inputs.
- We do not train models on your content, and the audit has no other outbound channel: no web search, no embeddings, no third-party scanner. The container that runs it talks to your repository, your domain, our own proxy, the model gateway, the npm advisory registry, and our own storage - and nothing else.
Two limitations we would rather state than omit. First, the agents are instructed never to write a secret's value into a finding, but they read what is in the file - so a key committed to your repository is seen by the model as part of the audit, which is one more reason the finding that reports it is worth acting on. Second, text already transmitted to a model host is governed by its terms, not by our deletion jobs: a later deletion removes the data from Hooldur; it cannot reach back into a completed inference call.
7. Who else receives data
We use service providers in these categories:
- Cloud infrastructure and data storage - Amazon Web Services
- Model inference - OpenRouter, and the hosts on the allowlist in section 6
- Code access - GitHub, through the GitHub App you install (read-only access to code and metadata)
- Database access - Supabase, through the authorisation or the read-only role you grant
- Sign-in - GitHub, Google, and Microsoft, only if you choose to sign in with one
- Email delivery - Amazon SES
- Website hosting and DNS - Cloudflare, for hooldur.com
- Vulnerability data - the public npm advisory database, which receives the names and versions of your dependencies
The domain check goes to your domain, not to a third party: a request that identifies itself as
Hooldur-Audit/1.0 (+https://hooldur.com) in your access log.
We do not sell personal data, and we do not share it for advertising.
8. Other disclosures
Beyond the providers in section 7, there are two situations in which personal data could leave Hooldur. Neither is routine, and we would rather name them here than have you learn of them the first time one happens.
When the law compels it. We may disclose personal data where we are legally required to: a binding court order, a valid demand from a law-enforcement agency or regulator, or where disclosure is necessary to establish or defend a legal claim or to protect someone's safety. We assess whether a request is valid and disclose only what it actually covers. Where the request concerns material inside an app you connected - the second column of section 2 - we will tell you so you can respond yourself, unless we are legally prohibited from telling you.
If the business changes hands. If Hooldur is acquired or merged, or its assets are sold, personal data may transfer to the acquirer as part of the business. It stays subject to this policy until a replacement policy is published, and we will tell account holders before that happens.
9. How we protect it
- Every customer is isolated from every other at the database layer. Every query runs under row-level security policies scoped to a single organization - a second, independent wall behind the application's own checks.
- Findings are encrypted under a key that belongs to one audit, and that key is wrapped under a master key we hold. Deleting an audit destroys its key, which is what makes deletion reach our backups: every copy becomes unreadable at once. Credentials you give us are encrypted under a separate key.
- The audit runs in a container that holds no database access and no key material. It receives a read-only GitHub token minted for that run, which expires in an hour and is never stored; it never holds your Supabase credential at all - it asks our proxy one of five named questions, and the proxy answers. Its outbound connections are the ones listed in section 6.
- Read-only is provable where it can be. The GitHub App asks only for read access to code and metadata. The read-only database role is checked when you paste it, and one that could read the rows of any table is refused. Authorised Supabase access asks for read scopes only, and cannot run SQL.
- Data is encrypted in transit (TLS) and at rest.
- There are no passwords to steal. Our sign-in methods (section 4) mean we never store one.
- Every endpoint is closed unless declared open, and the build fails if one is not; sign-in and other sensitive paths are rate limited.
- Every query against your database leaves a record - which named query, when, and whether it succeeded - so "we ran exactly these and nothing else" is a claim with a table behind it.
If a breach affects your personal data, we will notify you and, where the law requires it, regulators, without undue delay.
10. Where data is processed
Our own infrastructure runs in the European Union, in a single AWS region (eu-west-1, Ireland),
chosen for data residency. The Hooldur Team operates from Australia, and support is answered from
there.
The model hosts in section 6 are reached through a gateway and pinned to a named allowlist. We are documenting the specific processing locations of each of those hosts, and will state them here once established. We would rather leave this incomplete than describe a transfer arrangement we have not verified.
11. How long we keep it
We retain data for the life of what it belongs to and delete on an event, not on a timer. Findings do not expire on a schedule: an audit history is the point of running audits.
| Data | Retention |
|---|---|
| Apps, connections, audits, findings, transcripts, summaries, and the query record | Until you delete the app or close your account |
| Account record, linked sign-ins, and sessions | Until you close your account; a session expires 3 days after it was last used |
| Sign-in links, and the account-closure link | 5 minutes and 1 hour respectively, single use |
| The audit container's raw output, in object storage | Minutes - deleted once the audit is ingested; 7 days at most, as a backstop |
| Server logs | 1 month |
| Database backups | 7 days, disaster recovery only - and findings inside them are unreadable once the audit's key is gone |
| Model-call accounting (token counts, cost, host - no content) | Kept after you leave, as our cost record |
| Your answers to our questions (stored categories, no free text) | Kept after you leave, as the research they were collected for |
Deleting an app stops any running audit, revokes the Supabase authorisation at Supabase, deletes the audits and findings with it, and destroys their keys. The GitHub App stays installed, because it can serve your other apps. A read-only database role lives in your database, and we show you the statement to drop it.
Closing your account does all of that for every app, uninstalls the GitHub App so that we lose access to your code, and deletes your account. It is confirmed by a link we email you, which is live for one hour, and it takes effect immediately: there is no grace period, no soft delete, and no restore path. Nothing is exported first - the report is the artefact people would want, and handing over a bundle of decrypted findings is a decision we have not made yet.
What remains afterwards is exactly the last two rows of the table: accounting rows that carry an organization identifier but no content, and the categories you chose in answer to our questions. Neither holds a name, an email address, a finding, or a line of your repository.
12. Your rights
You have the right to access your data, to receive a copy in a portable form, to have inaccurate data corrected, to have data erased, to object to processing based on legitimate interests, and to restrict processing. You also have the right to complain to your data protection supervisory authority.
If the data is about you - you have an account, or you use our website - most of this is in your hands already: your name is editable on your profile, and deleting an app or closing your account is erasure, immediately. For anything else, including a copy of what we hold, write to [email protected] and we will respond within one month. There is no self-serve export today, so a copy is something we assemble for you.
If your data is inside an app someone else connected - section 3 - your route is through that person, who can erase it by deleting the app. If you are not sure who to contact, write to us and we will point you to the right place.
Before we act on a request, we check who is making it. A rights request is an obvious route to someone else's data, so we confirm it comes from the person it concerns before we action it, asking only for what we need to be sure. For data inside someone else's app, that check belongs to the person who connected it.
13. Cookies
We use no tracking cookies, no advertising cookies, and no third-party analytics cookies. That is why neither of our sites has a cookie banner. The only cookies in play are:
| Cookie | Where | Purpose |
|---|---|---|
better-auth.session_token | Application (my.hooldur.com) | Keeps you signed in. Essential |
hooldur_github_install_state | Application, while connecting GitHub | Proves the browser that finishes the connection is the one that started it. Essential to the flow; expires in ten minutes |
hooldur_supabase_state | Application, while connecting Supabase | The same, for Supabase. Ten minutes |
The application also remembers your light-or-dark preference in your browser's local storage, which is not a cookie and never leaves your browser. The website, hooldur.com, sets no cookies at all.
If we ever introduce a non-essential cookie or client-side tracking, this section changes first and the consent question is reopened.
14. Children
Hooldur is a tool for people who have built and run an app. It is not directed at children, and we do not knowingly collect data from them. If you believe a child has provided us personal data, contact us and we will remove it.
15. Automated decision-making
Our AI reads your app and proposes findings, fixes, and a grade. It does not decide anything about you, and it does not change anything in your app: the audit is read-only, every output is a suggestion, and you decide what to do with it. We do not carry out automated decision-making that produces legal effects or similarly significant effects.
16. Changes to this policy
We will update this page when the product changes in a way that affects it, and record every change below. Material changes will be communicated to account holders directly rather than left for you to notice.
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-08-23 | Initial Privacy Policy. |