Privacy

Who this is from

nth Labs is in beta. The operator of nth Labs is the data controller for everything described below, and the way to reach them is hello@nthlabs.dev. There is no registered company name or postal address to print here yet. When there is one it goes here, rather than being something you have to write and ask for.

There is no data protection officer. The law does not require one at this size, and appointing one in name only would tell you nothing. The address above reaches whoever decides what happens to your data.

What is stored, and where

Self-hosted or local: everything stays on your machine or your server. Your account email, a scrypt hash of your password and never the password itself, your API key, and every finding, verdict, guard and screenshot. We never see any of it. There is no telemetry and no analytics.

One stored thing deserves its own sentence: the sign-in recipe. If you configure agents to test past your product’s login, the test account’s email and password you typed are saved with that project, as they have to be for a browser to sign in with them on every run. Give that recipe a disposable test account, never a real user’s. Deleting the project deletes the recipe.

On a hosted console: the same data lives on that console’s disk, one directory per account, which is a boundary rather than a database row. Other accounts cannot read yours. The hosted beta runs on Railway, so that disk is a Railway volume, held under Railway’s own security terms the way the site sits on Vercel’s.

In a shared workspace: the projects, findings and stored keys belong to the workspace rather than to whoever typed them. Every member can see them at the level their role allows, and a run any member starts spends the workspace’s key, not their own. If that is not what you want, stay in a personal workspace, which is what you get by default and what you have unless somebody invites you.

What leaves the box

One thing. When a module needs judgement, screenshots and page text of the product you configured are sent to a model provider’s API, under that provider’s data terms, on your own key if you have set one or on the console’s key when you are spending credits. Which provider that is depends on the model, and the next paragraph but one says so exactly. Vitals, Guard and Changes send nothing anywhere: they are deterministic and call no model at all.

The report needs its own sentence, because running free and sending nothing are two different promises and it only keeps the first unconditionally. With no key it calls nothing. With a key it adds a written review on top, and that call sends a digest of what it reviews: your finding titles and severities, each module’s score and headline, and the titles of the ones you fixed. No screenshots and no page text. A finding’s title was written by a model that had just read your pages, so it carries some of that with it.

The CI gate is not on that list. The gate runs other modules on your behalf, and by default those are audit and readiness, both of which do call a model.

Which company receives it depends on the model the run uses, and that is a choice you make per run. The catalogue spans five providers (Anthropic, OpenAI, Google, Mistral and OpenRouter) and the hosted console offers every vision-capable model in it. The default model today is an OpenAI one, so a run you do not change the model on sends its screenshots to OpenAI, not to Anthropic. On your own key, your key decides. Whichever it is, the thing being sent is the same: your product, not you. But if a run is signed into your product, whatever that test account can see may be in a screenshot. That is the real reason to point runs at staging and to give them an account you would not mind an intern using.

If you connect an editor or an assistant

nth Labs can be added to Claude Code, Cursor, Codex, or Claude in a browser, as an MCP connector. When you do that, you are pointing another company’s assistant at your ledger, and it is worth being exact about what that means, because it is a data flow nobody else on this page describes.

A connected assistant acts as your account: reading what you can read (your findings, your run history, your readiness scores, the fix prompts) and starting runs, which spend whatever your runs spend. Everything a connector reads travels to whoever operates that assistant and is handled under their terms, not ours: Anthropic for Claude, the vendor of whichever editor you chose otherwise. We are not a party to that leg of the trip and cannot see it.

What a connector cannot reach: your password, your API keys, your product’s stored test-account sign-in, and any other account’s data. Those are not on the connector’s surface at all: not withheld by policy, absent from what the tools can return.

The credential is a token you mint yourself in Settings → Editor, or an authorisation you grant on a consent screen that names the app and where it will send you. Either can be revoked in the same place, and revoking stops it working on the very next request. If you would rather no third-party assistant saw a particular product’s findings, keep that product in its own project and do not connect an assistant while it is the active one.

One narrow exception, stated because it is the kind of thing that otherwise gets found later. If the console operator has configured a chat model that costs nothing to run, the questions you type into Chat are answered by that model instead of on your key, and the text of the question goes to whoever hosts it, and today the only zero-priced models in the catalogue are on OpenRouter. Runs never take that path. A run sends screenshots of an unreleased product, and that is not something to put on somebody else’s free tier.

Buying credits involves one more party. The payment happens on Stripe’s own checkout page, so your card details go to Stripe and never touch this console. What is stored here is the ledger entry your payment authorised: an amount, a time, and which account it belongs to.

Who else touches it

The complete list for the hosted service. A model provider only receives anything when a run uses one of its models, so most accounts will never touch most of this table. Any of them can, so all of them are named.

That last column is where the company is, not where a particular byte is sitting. A host’s region is a deployment setting; the company is what decides whose law reaches it.

Two more parties appear only if you pick them. Signing in with Google or GitHub tells that provider you are signing in here, and tells us your email address and whether the provider has verified it. Nothing else, and no access to anything else in your account there. Sign in with a password instead and neither is involved.

Run the software yourself and this table is one row long, your model provider, because there is no console of ours anywhere in the path.

Cookies

This website sets none. Not “no third-party cookies”: none.

The console sets three. All first-party, all strictly necessary, all HttpOnly so no script can read them. There is no analytics cookie, no advertising cookie and no third-party cookie anywhere in the product.

• nth_sid: your session. SameSite=Strict, and Secure on any connection served over HTTPS, which the hosted console is. Twelve hours, extended while you are using it. Set when you sign in, cleared when you sign out.
• nth_oauth: set only while you are signing in with Google or GitHub, for ten minutes, scoped to the sign-in routes alone. The cookie holds a random value that is compared when the provider sends you back; without it, somebody could complete a sign-in in your browser as themselves.
• nth_join: set only when you follow an invite link to a shared workspace, for thirty minutes. The cookie carries the invite across the sign-in you have to do first.

There is no cookie banner because there is nothing to ask you about. Every one of these is needed to do the thing you just asked for, which is the exception the rules already make.

What is never collected

No tracking pixels, no third-party analytics, no session recordings of you, and no sale or sharing of data with anyone. Your product’s findings are not training data.

Why we are allowed to hold it

Under the UK and EU rules, processing needs a lawful basis. Three are used here.

• To do what you asked: your account, the runs you start, the findings they produce, the key you stored so they can run, your credits and your invites. This is the contract between us, and refusing it would mean refusing the product.
• Because the law says keep it: the billing ledger. A record that a payment happened has to survive for bookkeeping, whatever it paid for.
• Because the thing has to stay standing: sessions, a count of failed sign-ins against an address, the server’s error log, and the audit line written when something happens that cannot be undone by looking at it. Our legitimate interest is keeping other people out of your account. Weighed against you it is narrow: none of it profiles you, none of it is sold, and the audit log refuses by field name to record a password, a hash, a token or a key.

Consent is not on that list, and its absence is the point: nothing here runs on it. There is no analytics to agree to, no marketing list, and no cookie that needs asking about.

How long it is kept

• Your projects, findings, verdicts, guards, screenshots, stored keys and sign-in recipes: until you delete them. There is no clock, because your findings history is the product’s memory of your product.
• A deleted account or project: the record goes at once; the files wait thirty days. See below, because this page used to say otherwise.
• Sessions: twelve hours, extended while you are using the console. Sign out and it ends in that moment.
• Failed sign-ins: the email address that failed and a count, for at most an hour, which is what makes guessing a password slow.
• Your IP address, held in memory only, for two jobs: rate-limiting failed sign-ins and throttling sign-ups, both of which need to know that many attempts came from one place. The hash is never written to disk, never joined to your account, and it goes when the counter expires or the console restarts. Under GDPR an IP address is personal data, so it is listed here even though nothing keeps it.
• The server’s error log: the last hundred errors, each a time, a place in the code and a message. No account, no address, no request body.
• The audit log: kept with the console’s state, rotated at 4 MB with one previous generation. The log records who did what and when, by email, and refuses secrets.
• Backups, where the operator has configured them: encrypted before they leave the box, the last thirty nights plus one a month for a year.
• The billing ledger: seven years after the payment, the outside edge of the bookkeeping rules that could apply. An amount, a time and an account. Never a card number, because we never have one.
• Email you send us: until you ask for it to go.
• This website’s request logs: Vercel’s, under Vercel’s retention rather than ours.

Deleting everything

Settings, then Danger zone, then “Delete my account” removes your account record, every project, and your stored API key. Deletion happens while you watch: the record is gone from every live path in the same moment, and every session signed in as you stops working. Single projects can be deleted the same way.

One correction this page owed you, because it used to say “immediately and unrecoverably” and the software changed underneath it. The files are not shredded on the spot. They move to a bin on the console’s disk and are swept thirty days later, so that pressing the wrong button is survivable. The likeliest way this data dies is not a disk failing, it is somebody meaning to press the other one. Nothing reads them while they wait, and labs undelete is the only thing that can bring them back. If you want them gone sooner than thirty days, ask and they will be.

The bin is not the last copy, and saying so would be the easier sentence rather than the true one. Backups are taken nightly, and the retention on them is the last thirty nights plus one a month for a year. So for up to a year after you delete something, a copy of it exists inside a backup archive: not readable by the console, not restorable to your account selectively, and only touched if the whole service has to be rebuilt after a disaster. Those archives age out on the schedule above, and that is when the last copy goes. If you need a deletion that reaches the backups too, ask, and it will be done by hand.

Until you delete it, data is simply kept, and there is no automatic retention window. The one thing that outlives an account is its billing ledger: a record that a payment happened has to survive for bookkeeping, though everything it paid for is gone.

Where it sits, and when it crosses a border

Run nth Labs yourself and nothing crosses anything except the call to your model provider. The findings are files on your disk, in whatever country your disk is in.

Use the hosted console and your data is on Railway, model calls go to whichever provider the run’s model belongs to, payments go to Stripe, and these pages come off Vercel. Every one of those is American except Mistral, which is French. nth Labs is operated from Toronto, Canada, so for Canadian users this is the disclosure PIPEDA asks for: your data is stored and processed outside Canada, in the United States, and while it is there it is subject to the laws of that country, including lawful access by its authorities. If you are in the EU or the UK, work on the same basis.

The lawful route for those transfers is each provider’s own published data processing terms, which incorporate the European Commission’s Standard Contractual Clauses, and in some cases that provider’s certification under the EU–US Data Privacy Framework. That is what this service runs on. There is no separately negotiated agreement with any of them, and if your organisation needs one, that is worth knowing before you sign up rather than after.

Your rights, and how to use them

Two of them you can exercise without us, right now. Reports export as a single HTML file from the console, and labs contracts export writes your guards out as standalone Playwright specs from the command line, so taking a copy is something you do, not something you request. Deleting everything is Settings, then Danger zone: no ticket, no conversation.

Nothing here is ever sold, and nothing is shared for advertising. Not as a policy that could be changed quietly: there is no advertising relationship to share it with.

In the EU or the UK

• Access: a copy of everything held about you.
• Rectification: anything wrong, corrected.
• Erasure: all of it deleted. The Danger zone does this; asking works too.
• Restriction: we hold it and stop using it while something is in dispute.
• Portability: the data you gave us, in a form a machine can read. The exports are already that; ask and you get the rest.
• Objection: to anything done on legitimate interests, which are listed above rather than left for you to guess at.
• Withdrawing consent: nothing here runs on consent, so there is nothing to withdraw. Consent is on the list because leaving it off would read as an omission.

No automated decision-making produces a legal effect on you. The models judge software, not people.

In California

• Know: what is collected, why, and who it reaches. This page is that answer and the table above is the list.
• Delete: the Danger zone, or an email.
• Correct: anything inaccurate.
• Opt out of sale or sharing: there is nothing to opt out of. No personal information has been sold, or shared for cross-context behavioural advertising, in the last twelve months or at any point before them. There is no “Do Not Sell” link because there would be nothing behind it.
• Limit the use of sensitive personal information: none is collected for any purpose this right restricts.
• No retaliation: using any of these changes nothing about your account, your price or your access.

How to actually use one

Email hello@nthlabs.dev from the address on your account and say which one you want. That is the whole procedure; there is no form. You get an answer inside thirty days and usually the same week, because the person reading it is the person who can do it. If we ever need to check it is you, it will be something you can already prove from the account itself, never a photograph of your passport.

And if you think we have handled your data badly, you can complain to a regulator without asking us first. nth Labs is operated from Canada, so the authority with oversight is the Office of the Privacy Commissioner of Canada (priv.gc.ca). In the EU it is your national data protection authority, in the UK the Information Commissioner’s Office, and in California the Attorney General or the California Privacy Protection Agency. We would rather hear it first at support@nthlabs.dev, but nothing here asks you to come to us before you go to them.

Children

You have to be 13 or older to create an account, which is what the terms say as well. Under 18, the person who agrees to those terms is a parent or guardian. Nothing here is built for children or aimed at them, and we do not knowingly hold anything belonging to someone under 13. If we find that we do, the account and its data go without waiting to be asked.

What actually protects it

The security page covers this properly. The short version, limited to things that are actually built:

• One directory per account, not a row in a table. An account’s data lives under its own path, and the id in that path comes from the system’s cryptographic random number generator and is validated on the way in, so no id can walk out of the accounts root. A boundary, rather than a filter every route has to remember.
• Passwords are salted scrypt hashes, never plain text. scrypt is slow and memory-hard on purpose.
• State files are written owner-only, so nothing else on the box reads them.
• The session cookie is HttpOnly and SameSite=Strict, and carries Secure over HTTPS.
• Both surfaces send a Content-Security-Policy, and the console adds HSTS on a secure connection.
• A run cannot point a browser inward. The hostname is resolved first and the addresses behind it are judged, and loopback, link-local, private ranges and cloud metadata endpoints are all refused. The address actually landed on is checked again.
• Sign-ins are rate-limited, with a lockout that escalates.
• The audit log refuses secrets by field name. A password, hash, token, key, cookie or session handed to it is dropped and the refusal written in its place.

What there is not: no SOC 2 report, no ISO certificate, no independent penetration test, and no third-party audit of any of the above. There is nothing to point at yet, and we would rather write that than imply one.

If something goes wrong

If your personal data is exposed, you get an email. Not a status page and not a line in a changelog: the address on your account, with what happened, what of yours was in it, what has been done, and what you should do. Where the law puts a clock on it (seventy-two hours to the relevant authority under the UK and EU rules) we work to that clock, and we would rather send you an incomplete account inside it than a tidy one afterwards.

The same address takes reports in the other direction. If you find a way into somebody else’s data here, hello@nthlabs.dev.

This website

The page you are reading is static HTML. There is no analytics script, no tag manager, no session recorder, no advertising pixel and no cookie of any kind. Nothing on it contacts a third party while you read it, and the fonts are served from this domain rather than a font CDN. There is no account and no login here.

The site is hosted on Vercel, which keeps ordinary server request logs the way any web host does. Those logs are Vercel’s, made in the course of serving the page, and we do not join them to anything or use them to build a profile of you.

If you email us

Writing to hello@nthlabs.dev, including to ask for beta access, means we hold your message and your address in our mail. We use it to reply to you and to run the beta. We do not sell it, rent it, or add you to a marketing list you did not ask for. Ask us to delete it and we will.

When this page changes

The date at the top is the changelog. If something material changes, whether that is a new party in the table above, something new collected, or a retention period moving in either direction, account holders are emailed before it takes effect, not after. Corrections like the one about the recycle bin land with a new date and no email.