Security at nth Labs

A run dereferences a URL somebody else typed, in a browser, inside the box that holds every other account’s state. That is the whole threat model.

• One of those callers has no account. The free check on the landing page runs from a public endpoint, so a URL can reach a browser here with no session behind it. Nothing the engine can do is narrower: one page, no crawl, deterministic checks only, no model key reachable from it. The fence around it is its own, the address is judged by the same guard below before anything launches, the child process is killed at ninety seconds, two may run at once, and three per address per hour. Its state is a scratch directory that is deleted when it finishes.
• The name is resolved before it is judged. A public hostname may resolve into private space; loopback, link-local, the private ranges and the cloud metadata endpoints are refused, and one private answer refuses the whole run.
• The address landed on is checked again. DNS can change between the check and the fetch, and a redirect can arrive somewhere the first gate never saw. The pre-flight check is the first gate, not the only one.
• Model output is untrusted input. Every model answer is escaped at every render site, capped in length at the store boundary, and never interpolated into generated code.
• Both surfaces send a Content-Security-Policy, the console with a per-response nonce, and it adds HSTS on a secure connection.

Scoping is a boundary rather than a filter each route has to remember. Two cross-tenant bugs here had exactly that shape, and both were routes that forgot.

• One directory per account, not a row in a shared table. The id in the 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.
• State files are written owner-only, so nothing else on the box reads them.
• 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.
• An archive you move can be redacted, and the redactor names the fields it cleared rather than promising about a file it did not understand.

Where this stops: neither your model key nor your product’s sign-in password is encrypted at rest. Owner-only permissions and the account directory protect them. Give the console a throwaway test account.

Six of the eight checks never send your product anywhere. Two of them do, and the page says which, because a blanket privacy claim over a tool that calls a model is not true.

• Speed & errors, Re-checks and Report run entirely in a browser on your machine. No API key, and nothing leaves.
• Site review and Test drive send page text and screenshots to the model whose key you configured, and to nobody else. The provider is yours, the key is yours, and the bill is yours.
• Findings are files, not rows in our database. On the default local install there is no server to send them to.

• Passwords are salted scrypt hashes. A digest that is cheap to compute is cheap to attack; scrypt is slow and memory-hard on purpose.
• Secrets are compared in constant time. Comparing with === leaks the prefix through how long the comparison took.
• The session cookie is HttpOnly and SameSite=Strict, and carries Secure over HTTPS. The OAuth state cookie is scoped to the auth path alone.
• A read-only viewer cannot write config, spend, or erase. That is a test, not a convention.
• Sign-ins are rate-limited with an escalating lockout, and account creation is limited too. Each new account costs a directory and about a tenth of a second of scrypt, which is a denial-of-service primitive if it is free.
• Signups on a hosted box are closed by default. An invite link is a one-time credential (checked for shape, workspace, expiry and prior use), and a cookie that is merely present opens nothing. The link is read at the form and only spent when an account is actually seated.
• There is no second factor yet. A hosted account is a password, rate limiting and a lockout. Not a password and a phone. Invite-only signups and the throwaway-test-account rule are the fence around that gap until it closes.

The product’s pitch is that a claim nobody re-tested is not evidence. The same rule is turned inward here.

• A guard must be seen to fail before it counts. The test is written against the unfixed code and watched going red; a test written after the fix proves the code passes the test, not that the test would have caught the bug.
• A security fix ships as the exploit, inverted. The regression test is the attack that worked.
• Every push runs a secret scan before anything else in the chain.
• Roughly 1,650 tests across the engine, the console and the CLI, plus a browser suite driving real Chromium.

• Local by default. The console binds to the loopback interface, and hosting is a mode you turn on rather than a config value you can fat-finger.
• The two modes are different threat models, not a setting apart. The guard is stricter in the one where the URL arrived from a stranger.
• No build step and no bundler. Plain CommonJS on Node 20+, so the dependency surface an attacker inherits is the one you can read in the lockfile.

The endpoint that matters here is the browser a run steers, because that is the thing holding your product’s session.

• A signed-in run uses a session you exported from your own browser, so the sign-in happened where you were. No password recipe, no bypass of your SSO or 2FA.
• Every step it took is in the transcript, in the tester’s own words, next to the frame it was looking at when it took it.

• Outbound: your product, and your model provider. There is no telemetry endpoint, and no analytics beacon on the console.
• Inbound on the default install: nothing. Loopback only.
• Inbound on the hosted console: the sign-in routes, Stripe’s webhook, and the free check. Everything else needs a session. The free check is the only one that does work for a caller with no account, which is why it is fenced the way the threat model above describes.
• The site you are reading contacts nothing. Static HTML, no tag manager, no session recorder, no pixel, no cookie, and the fonts are served from this domain rather than a font CDN.

Run it yourself and the answer is your disk, in whatever country your disk is in. The hosted console is the case worth stating.

• There is no automatic retention window. Until you delete something, it is kept. The one thing that outlives an account is its billing ledger, because that a payment happened has to survive seven years for bookkeeping, though everything it paid for is gone.
• Backups are nightly where the operator has configured them, encrypted before they leave the box, kept for the last thirty nights plus one a month for a year.
• Deletion reaches the backups only on request. For up to a year after you delete something a copy exists inside a backup archive: not readable by the console, not selectively restorable, and touched only if the whole service has to be rebuilt. Ask and it is done by hand.
• The hosted console runs on Railway; payments go to Stripe; these pages come off Vercel; model calls go to whichever provider the run’s model belongs to. nth Labs is operated from Toronto, so data on the hosted console is stored and processed outside Canada, in the United States.

The full table, including the lawful basis for those transfers, is on the privacy page.

• You get an email, not a status page. The address on your account, with what happened, what of yours was in it, what has been done and what you should do.
• Inside seventy-two hours to the relevant authority, where the UK and EU rules put that clock on it. We would rather send 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, write to us.

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

Neither key material nor stored passwords are encrypted at rest. There is no bug bounty. If you need either before adopting a tool, we would rather you knew now.

Found a way into somebody else’s data here? hello@nthlabs.dev, the same address the privacy page gives. We will answer, and we will say what we fixed.