Legal
Privacy Policy
Draft — not reviewed by counsel, not in force
This page is sourced directly from the draft in docs/legal/. It was written by
reading superdev's own schema and deployment configuration, and it is not legal advice.
Bracketed placeholders like [EFFECTIVE DATE] mark facts a lawyer still has to fill
in — they are left visible rather than guessed at.
Effective date: [EFFECTIVE DATE]
Controller: [LEGAL ENTITY], [REGISTERED ADDRESS]. Contact: [PRIVACY CONTACT].
This policy covers the superdev service and the process of requesting access to it. The superdev plugin is separate: it runs on your machine, holds your key locally, and sends nothing to us except the API calls you make.
The short version
We hold very little about people. Most of what we hold is your product plans, which is commercially sensitive rather than personal. Three specifics are worth knowing up front, because they are properties of how the system is built rather than promises we are making:
- We never store your API key. Only a SHA-256 of it, hashed before it reaches the database, so the raw value never appears in a log or a query statistic.
- Our request log holds no request bodies, no headers, and no query strings. Only method, path, status, duration, and who was calling.
- Everything is in the United States. Compute in Ashburn, Virginia; the database in AWS
us-east-1.
And one that is less comfortable and belongs here rather than in a footnote:
- Our operators can access all customer data. The database has no account boundary yet; isolation between customers is enforced by row-level security against a product-scoped key. The beta is invite-only partly for this reason. See section 7.
1. Two roles, and which one applies
We are a controller for information about you as a user of our service: how you asked for access, who you are, and how your keys are used.
We are a processor for the content you put in the backlog. You decide what goes in it. If it contains personal data, you are the controller and we process it on your instructions — see the DPA (not yet published), and note that our terms ask you not to put personal data in there in the first place.
2. What we collect as controller
When you request access
Our access-request form is a GitHub issue form, so GitHub processes it and the issue is public. The form says so and asks you not to put anything sensitive in it. We collect:
| Why | |
|---|---|
| What you are building, and your preferred product slug | To create your product and judge fit |
| How many agents you expect to run | To decide how many keys to issue |
| How you get work to your agents today | Research — it tells us where this fits in what you already do |
| An email address | To send your keys, which we do not send through the issue |
[DECISION] — a public issue tracker is an unusual front door for a signup and it makes the
request itself public. It was chosen because it needs no infrastructure. If that is not acceptable,
the alternative is a hosted form, which adds a subprocessor.
When we issue you a key
- A label describing who or what the key is for. These are written by our operators and, by convention, often contain a person's name or a machine name — "alex laptop". That makes them personal data, and it is the most person-identifying field in the system.
- The key's SHA-256, prefix, role, product scope, and expiry. Never the key.
- The time it was last used. One timestamp per key, overwritten on each use.
When you use the service
One line per request, retained for 90 days and then deleted by a scheduled job:
| Field | Note |
|---|---|
| Time, HTTP method, path, status, duration | |
| Key prefix | The public leading segment. Identifies the credential, is not one |
| Agent identifier | Whatever your client declared. Yours to choose; it does not need to be a person |
| Role, and whether you were rate-limited |
Not collected, deliberately: request bodies, any header, the query string, and the API key in any form. Each of those is a decision recorded in the code that writes the log, not an oversight we might correct later.
Communications
Emails you send us and we send you, kept while we have a relationship and for [RETENTION]
afterwards.
3. What we collect as processor
Your backlog content: products, capabilities, features, user stories, acceptance criteria, work items, notes, evaluations, and evidence signals. These are free-text fields and we do not inspect them.
Two fields in this category commonly identify a person: the author on a work-item note and
the claimed_by on a work item. Both are declared by your client, and both can be an agent name
rather than a person's.
4. Why we process it, and on what basis
[COUNSEL] — the legal-basis column assumes GDPR applies. If EU and UK customers are out of scope
for the beta, this table simplifies and section 8 changes.
| Purpose | Basis |
|---|---|
| Providing the service | Contract |
| Issuing, scoping, and revoking keys | Contract |
| Security: detecting abuse, investigating incidents, rate limiting | Legitimate interests — running a service safely |
| Understanding how the beta is used, so we know what to build | Legitimate interests — the beta exists to answer this |
| Answering your emails | Contract, or legitimate interests |
| Meeting legal obligations | Legal obligation |
We do not use your content or your usage to train machine-learning models, and we do not sell personal data or share it for advertising.
5. Who we share it with
Only our subprocessors list (not yet published) — Fly.io, Supabase, and GitHub — each doing one job, each listed with what it holds and where.
We may also disclose where the law requires it. If we receive a legally binding demand for your data we will tell you unless we are prohibited from doing so.
We do not sell personal data.
6. How long we keep it
| Retained | |
|---|---|
| Request log | 90 days, then deleted by a scheduled job that runs daily |
| Key records, including the hash and label | While the key exists; after revocation, [RETENTION] |
| Backlog content | Until you ask us to remove it — subject to section 7's real limits |
| Access-request issues | Public on GitHub until closed and deleted; [DECISION] on whether they are deleted at all |
| Emails | [RETENTION] |
7. Your rights, and where this service cannot yet honour one
You may ask us to access, correct, export, or delete your personal data, to object to or restrict
processing, and to complain to a supervisory authority. Write to [PRIVACY CONTACT]; we will
respond within [RESPONSE TIME].
Deletion needs a plain warning, because this system is unusual and we would rather say so than be discovered.
The backlog is built so a record of a decision outlives the thing it described. Concretely:
- No customer-facing role can delete anything. Removal is a lifecycle state; the row remains.
- Evaluations, evidence signals, and work-item notes cannot be edited or deleted even by us without an operator disabling a database trigger.
- The procedure that would erase one customer's data completely is designed and not built.
So today an erasure request is satisfied by hand, and we will tell you what was removed and what
was retained. If your compliance position requires a guaranteed erasure timescale, raise it before
you start using the service. [DECISION] — the commitment we can make, and the deadline for
building the procedure that would let us shorten it.
On operator access: our personnel can technically read any customer's data. Access is limited to those who need it to run the service, and is a small, known set. There is no account boundary in the database enforcing it — enforcement is by row-level security against a product-scoped key, which constrains the service and does not constrain someone holding a database credential.
8. International transfers
All processing is in the United States: Fly.io in Ashburn, Virginia; Supabase in AWS
us-east-1; GitHub in the United States.
[COUNSEL] — if EU or UK personal data reaches us, this section needs a transfer mechanism
(Standard Contractual Clauses, plus the UK Addendum) and a transfer impact assessment. That is a
decision about who the beta is sold to, not a drafting question. See README.md §4.
9. Security
- TLS on every connection to the API.
- API keys are hashed before storage. Only the SHA-256 and a public prefix are kept.
- Keys expire — 90 days by default — and can be revoked immediately.
- Each key carries one role and normally one product; the database enforces what it may read and write, not the application.
- Rate limits and a request-size cap per key.
- A request log, so an incident can be investigated.
What we do not yet have, said here rather than implied: point-in-time recovery (backups are daily, kept seven days), a rehearsal of our provider's own restore, a second region, an account boundary in the schema, and an independent security assessment.
No system is perfectly secure. If you find a problem, write to [SECURITY CONTACT] — see the
Terms, section 4, for our position on good-faith research.
10. Children
The service is for businesses. It is not directed at children and we do not knowingly collect their data.
11. Changes
We will post changes here and update the effective date. For a material change we will contact you
at the address we hold, at least [NOTICE PERIOD] before it takes effect.
12. Contact
[PRIVACY CONTACT] · [LEGAL ENTITY], [REGISTERED ADDRESS].
[COUNSEL] — whether a Data Protection Officer or an EU/UK representative is required follows
from the answer in section 8.