Signoos Privacy Policy
Signoos connects to a repository you choose, helps your team delegate and review work in it, and can use AI models to do specific jobs on your behalf. That means we hold things that matter: your account, your team's work, and — only if you allow it — your source code. This policy says exactly what we hold, who else sees it, how long it stays, and how to make us delete it.
Who we are
Signoos operates the service at signoos.com and is the data controller for the personal data described here.
Provisional. Signoos is currently operated by an individual rather than an incorporated company, and that person is the controller. We will publish the registered entity and its postal address here as soon as one exists, and will give notice of the change under “Changes to this policy”. If you need the controller’s full legal identity and a postal address before then — to exercise a right, or to complain to a supervisory authority — ask at [email protected] and we will give it to you.
You can reach us about anything in this policy at [email protected].
What we collect
Account information
- Your email address, first and last name, and your username.
- A password, if you registered with one. It is verified by our sign-in backend and is never stored by us between the steps of registration.
- If you use two-factor authentication: your enrolled secret, held encrypted, and recovery codes, held only as one-way hashes.
GitHub identity and installation
- If you sign in with GitHub: your GitHub login and numeric account id, and the email address GitHub gives us for the account.
- When you connect a repository: the installation number of the Signoos GitHub App. That is all we store — see How we protect it.
Security and device records
- IP address and user-agent string, written into our security event log on authentication and authorization events. We are being precise here rather than reassuring: these are recorded in full in those log lines.
- For the “where am I signed in” list on your account, we store a deliberately reduced description instead: your browser family (Chrome, Firefox, Safari…), your platform, and your address truncated to a network prefix — enough for you to recognise your own laptop, not enough to be a fingerprint. At most twenty sessions are kept; the oldest is dropped.
- If you connect the command-line client or an editor: a device record with a name you choose and the IP address the device last used.
- On registration and password reset we store a hash of your IP address rather than the address, for abuse limits.
The mobile app
- A push notification token, only if you turn notifications on for a device. It is bound to that one session, you can mute or remove it from the account tab, and it is deleted when the session ends. See Sub-processors for who handles delivery and what they receive.
- What the app keeps on your phone. Exactly two things are held in the device keystore — your sign-in credential and the key that encrypts the app’s local cache — both marked available only while the device is unlocked, and only on that device. Everything else the app stores locally is non-secret: which project you last opened, your theme, whether you have seen a notice.
- Crash reports: none are collected today. The app ships the ability to send them and it is switched off — no crash-reporting endpoint is configured, so nothing is sent. If that ever changes we will say so here first, and the scrubbing is already written: request bodies, credentials and query strings are removed before an event could leave the device.
- No advertising or analytics library is present in the app at all. Not disabled — not there. There is no advertising identifier, no attribution SDK and no session recorder.
Your content
- Projects, tasks, tickets, messages and team membership — everything you and your team type into Signoos, including task descriptions, thread replies, AI review results and solver output. Solver records contain verbatim excerpts of your code and the patch text.
- Review sources you add for Insights, and the review text fetched from them.
- Mirrored repository source code — only under the consent described below.
- API keys you store for AI providers or Jira, held encrypted and never returned to anyone, including you.
AI usage counters
Every model call writes a metering record: the project, the role, the model, the exact input and output token counts, an estimated cost and a duration. These are what enforce your spend ceilings. They record that a call happened and how big it was — not the content of the call.
What we do not collect
We run no analytics product, no advertising network, no session recorder and no third-party tracking script of any kind. There is no advertising cookie to reject because there is no advertising. We do not buy personal data, we do not sell it, and we do not share it for behavioural advertising.
Your source code
We read no code until you say so. A project is created with code access off. Turning it on is an explicit choice, and it is scoped folder by folder: you pick which folders may be read, matching runs per path segment, and the check is enforced in one place that every read passes through — the index, the localizer, the mirror and the file browser alike. If the rule cannot be evaluated, the read is refused rather than allowed.
With consent granted, the repository is mirrored so your team can browse it inside Signoos, and code may be sent to AI providers for the jobs listed on the AI processing page. Withheld folders are filtered out before anything is stored or indexed.
One honest limit. Narrowing your consent stops every new read immediately. It does not retract a file path and line range already written onto an open task or ticket by an earlier, wider consent. Those are records that were created while the read was permitted. Deleting the task, the ticket or the project removes them.
Why we process it, and on what legal basis
Where the UK GDPR or EU GDPR applies, these are our lawful bases:
- Performance of a contract — running your account, your projects, your team, the repository mirror, tasks and reviews. Without this data there is no service to provide.
- Consent — reading your source code and the folders it applies to; connecting a repository; adding review sources; the optional work-notice emails. You can withdraw any of these at any time, in the product, and withdrawal takes effect for everything that happens afterwards.
- Legitimate interests — keeping the service secure and available: authentication and session logs, rate limits, bot resistance on the sign-in forms, device records, and spend metering to stop runaway or abusive AI use. We have balanced these against your interests and kept them narrow — which is why the session list stores a truncated address and a browser family rather than a fingerprint.
- Legal obligation — where we must retain or disclose something to comply with the law.
We do not use your content for automated decision-making that produces legal or similarly significant effects about you. AI output in Signoos is advisory: it never closes work and never merges anything. The most it can put in your repository is a commit on a branch with a pull request for your team to review, and only where your team leader has left pushing switched on — clause 5 of the Terms states the bounds in full.
Sub-processors
We use the following service providers. Each one is named, with what it actually receives and why.
| Provider | What it receives | Why |
|---|---|---|
| GitHub | Your GitHub account identity (login and numeric id) when you sign in with GitHub, and the repository requests made under the installation you approved. | The repository connection itself: reading the repository you chose, and signing in with GitHub if you use that door. |
| Google Cloud Platform | Everything stored by the service — account records, projects, tasks, tickets, the mirrored repository, logs — plus the sealed key material held in Cloud KMS. | Hosting, database, file storage, key management and the sign-in backend. This is where Signoos runs. |
| Cloudflare | The network metadata of every request — your IP address, request headers and the URL — plus the Turnstile anti-bot challenge on sign-in, registration and password reset, which is sent your IP address. | DNS, TLS termination, denial-of-service protection, the content-security-policy edge worker, and bot resistance on the three unauthenticated forms — on the web and in the mobile app. Turnstile is covered by Cloudflare’s Turnstile Privacy Addendum, linked under Cookies below. |
| Brevo | Your email address and the contents of the message being sent. | Transactional email: verification codes, password resets, security alerts and the optional work notices you can switch off. |
| Expo (Expo Application Services) | If you use the mobile app and turn on notifications: the device’s push token, the fixed notice sentence being delivered, and the project and task identifiers the notification links to. It relays these to Apple’s or Google’s push service. It receives no task text, no code, no diffs and no message content — the notice wording is chosen from a fixed list on our side, never composed from your data. | Delivering push notifications to the mobile app. Nothing is sent unless you enable notifications on that device, and turning them off on the device stops it. |
| OpenAI | The AI payloads described on the AI processing page — which, depending on the job and on your consent, may include source code, diffs and task text. Review mining and the search index always run here. | AI models for the roles assigned to them, plus the two pinned jobs. |
| Anthropic | The AI payloads for whichever roles are assigned a Claude model. | AI models for the roles assigned to them. |
| Google (Gemini) | The AI payloads for whichever roles are assigned a Gemini model. | AI models for the roles assigned to them. |
| Atlassian (Jira) | Only what your own Jira queries need, and only if you connect Jira to a project. | Optional roadmap source. Not used unless you connect it. |
Which AI providers see anything of yours depends on your own configuration and on whose provider account funds the work. The AI processing page sets that out job by job, including the two jobs that always run on OpenAI.
How long we keep things
Your account and your projects
Account and project content is kept for as long as the account exists. When you delete a project, it enters a 30-day retention window during which you can restore it. After that window the purge runs and the data is gone — the project record, its tasks, checks, solver runs, threads, tickets and its mirrored files in storage. Deleting your account deletes your account record and the projects you own on the same basis.
Short-lived records, deleted automatically
These carry an expiry and are swept by the database's own time-to-live policy:
- Sign-up codes, password reset tokens, email change tokens and pending GitHub sign-ups — 15 minutes.
- Sign-in and installation handshake records — 10 minutes.
- Command-line device authorization challenges — 5 minutes live, 60 minutes for the record of the outcome.
- Spent device refresh tokens (kept so a replayed token is detected as a replay) — 90 days.
- Sandbox execution sessions — 45 minutes.
- AI spend ledgers — 40 days. Free-tier request counters — 2 days.
- Webhook delivery records — 24 hours. GitHub revocation markers — 2 hours.
- Rate-limit counters — the length of the limit's own window, from ten minutes to twenty-four hours.
Expiry and deletion are not the same instant. An expired record stops working the moment it expires — every route refuses it — and the sweeper physically deletes it on a best-effort basis, normally within 24 hours of expiry.
Logs
Security and application logs are retained by our hosting provider under its default retention. One log we cannot shorten: Google Cloud records a data-access audit entry when a sandbox execution is launched, and that entry is retained by Google for approximately 400 days with no option to disable it. It contains no code and no credential.
Your rights, and how to exercise them
Subject to the law that applies to you, you have the right to access your personal data, to have it corrected, to have it erased, to receive it in a portable form, to object to processing based on our legitimate interests, to ask us to restrict processing, and to withdraw consent at any time without affecting what was lawful before you did.
Concretely:
- Correct your details — your name, username and email are editable in your account settings.
- Withdraw code-access consent — turn code access off, or narrow the shared folders, in the project's settings. It takes effect for every read from then on. See the limit noted under Your source code.
- Disconnect GitHub — uninstall the Signoos GitHub App from your repository on GitHub. Access ends immediately and completely, because we hold no credential that could outlive it.
- Delete a project — from the project's settings. Thirty days to change your mind, then it is purged.
- Delete your account — in your account settings. This removes your account and the projects you own, on the retention basis above.
- Get a copy of your data, or ask us to restrict or stop processing — email [email protected] from the address on your account. We will respond within one month, and will tell you if we need longer and why.
- Turn off optional emails — work notices are a setting; security and account emails are not, because they are how we tell you something happened to your account.
We do not charge for any of this and we do not require a particular form of words. If you are in the UK or the EEA and you think we have got something wrong, you can complain to your national supervisory authority — but we would rather you told us first.
International transfers
Signoos runs on Google Cloud Platform, and the sub-processors above are established principally in the United States. Your data is therefore processed outside the United Kingdom and the European Economic Area.
Where personal data is transferred out of the UK or the EEA, we rely on the transfer mechanism each provider offers in its published data-processing terms — for the providers listed above, the European Commission's Standard Contractual Clauses and the UK Addendum, together with the technical measures described below. You can ask us for details of the arrangements for a particular provider at [email protected].
How we protect it
- Everything is encrypted in transit. HTTPS end to end, strict transport security with a one-year maximum age, and cookies the browser refuses to send over plain HTTP.
- We store no GitHub credential of yours. Not a token, not a password. Connecting a repository stores an installation number; every request mints a fresh token from that installation, valid for an hour, scoped to the single repository the project uses, and held only in memory. Nothing to leak and nothing to rotate. (For completeness: the GitHub App has a private key of its own, which is a credential of our deployment, not of your account.)
- Provider keys you store are sealed twice. Each is encrypted with a single-use key, and that key is itself wrapped by Google Cloud KMS, bound cryptographically to the project, owner and provider it was stored for. A copy pasted into another account's record fails to decrypt rather than opening somebody else's. No endpoint ever returns a stored key.
- One-time secrets are never stored as secrets. Verification codes, reset tokens, device tokens and recovery codes are held only as one-way hashes and compared in constant time.
- The database refuses browsers outright. No client can read or write our data store directly; every byte travels through our API, which checks your session, your CSRF token, your membership of the project and your rate limits first.
- Your code is read only under folder consent, enforced fail-closed in one module every read passes through.
- Executed code is isolated. Where a project has an execution sandbox, the repository's own declared commands run in a throwaway container with no credentials in it, as an unprivileged user, on an identity that holds no permissions at all.
- Logs avoid identifiers where they can. Email addresses appear in logs only as truncated hashes. IP addresses and user-agent strings do appear in security events, as stated above — we would rather tell you that than imply otherwise.
Our vulnerability disclosure policy is at /.well-known/security.txt. If you find a problem, we want to hear about it: [email protected].
Children
Signoos is a tool for professional software teams. It is not directed at children, and we do not knowingly collect personal data from anyone under 16. If you believe a child has created an account, tell us at [email protected] and we will delete it.
Changes to this policy
When this policy changes we update the date at the top of the page. For a change that materially affects how we handle your data — a new sub-processor that receives your content, a new purpose, a longer retention period — we will tell you in the product and by email to your account address before it takes effect, so that you have the chance to object, export or delete first.
Contact
Privacy questions, data requests and complaints: [email protected].
See also the Terms of Service and the AI processing page.

