What the code does, and what it does not have.
There is no certification on this page and no posture. netweft holds no SOC 2 report and no ISO certificate, and a security page that implies otherwise is the one lie that would actually matter here. What follows is what the build does — and then, at the foot, the four things it does not, because that half is the half worth reading.
Passwords are checked, hashed and verified by code
Sign-in is Google, GitHub, or an email address and a password. A password must be 10 to 128 characters, is refused if it appears in a known breach (only the first five characters of its SHA-1 leave netweft, so the password itself is never sent), and is stored as a salted scrypt hash. An email account is not usable until a six-digit code sent to the address is entered; a code lives five minutes and allows three wrong attempts, and a password is reset with a code rather than a link.
Sign-in is rate limited and bot checked
Every request that signs in, creates an account or sends an email must carry a Cloudflare Turnstile token, and sign-in paths have their own per-address rate limits: ten sign-in attempts a minute, five sign-ups and three code requests. Resetting a password signs out every other session.
Google access is asked for late and narrow
Search Console and Analytics access is requested per project, at the moment that project connects them, and both scopes are read-only. An account that never connects either never grants them. The scopes are not bundled into sign-in, which is the usual way a tool ends up holding more access than it needs.
Keys are hashed, and compared in constant time
An API key is generated as three parts — a fixed prefix, a public random prefix and a secret — and shown once. Only its SHA-256 hash is stored. A request is looked up by the public prefix and decided by a constant-time comparison against that hash, so a key cannot be recovered from the database and a timing difference cannot be measured against it.
Keys are scoped, expirable and revocable
Every key is narrowed to some of 6 scopes when it is created, can be given an expiry, and can be revoked. Revoking leaves the row in place: the audit log still shows that the key existed and what it could reach, which is the part that matters after the fact. A scope this build does not recognise is dropped rather than honoured, so a row written by a newer deploy can never widen a key here.
Roles cannot act on peers
A workspace has owner, admin, member. Everything an admin can do, plus owners and the workspace. Manages keys, projects, billing and people. Cannot delete the workspace. Reads everything and works in projects. No keys, no billing, no people. Nobody may act on a peer — an admin cannot demote another admin — so a compromised admin account cannot lock out the rest of the workspace's administration.
Cross-site requests and oversized bodies are named failures
A state-changing request that arrives with a browser's ambient credentials but without proof that netweft's own dashboard sent it is refused with a distinct code, not a permission error. Request bodies have a documented cap, and every field a route accepts has a maximum well inside it, so an oversized body is a runaway client rather than a legitimate large request.
Spending is bounded, and the bound is named
Every paid operation reserves credits before the vendor is reached, and a workspace that cannot cover the call is refused with the shortfall named. There is no overage and no post-hoc invoice. The one way past the balance is auto top-up, which is on by default and charges the saved card at most $60 a day; with it switched off, a key that leaks cannot spend beyond the credits the workspace already holds. No MCP tool spends a credit at all.
No card data ever reaches netweft
Payments run on Polar, which is the merchant of record. netweft never sees a card number, never stores one, and does not handle the checkout, the invoices or the tax. What it stores is which plan a workspace is on and what it has left.
What netweft does not have.
One person builds netweft. That is the reason for most of what follows, and it is not going to be dressed up as a roadmap item with a quarter against it.
- No certifications and no audit report
- netweft holds no SOC 2 report, no ISO 27001 certificate and no completed third-party penetration test. If your procurement process requires one, netweft cannot pass it today, and no amount of wording on this page changes that.
- No SSO beyond Google and GitHub, and no SCIM
- Sign-in is Google, GitHub or an email and a password, and nothing else. There is no SAML, no OIDC against your own provider, and no SCIM provisioning. A company that must own its own identity provider cannot use netweft.
- No DPA, and the sub-processors are the ones named here
- There is no signed data processing agreement on offer and no published sub-processor list beyond what this site already names: Cloudflare for hosting, the database and bot checks; Google and GitHub for sign-in, and Google for the two read-only connections; DataForSEO for SEO data; OpenRouter for the AI model calls; Resend for email; PostHog for product analytics; Polar for payments.
- No bounty programme
- There is no bug bounty and no formal disclosure programme. Reports go to the same address as everything else, and the same one person reads them.
Reporting something
Send it to hello@netweft.com. There is no bounty and no triage queue — there is one person, and they will answer. If you would rather read the code paths this page describes than take its word for them, the API page and the MCP page name them specifically.
Nothing here asks you to take it on trust.
Every claim above is about a mechanism rather than a standard, which means it is checkable by using the product rather than by reading a certificate.
There is no free tier. Three plans from $50 a month, each opening with a free trial.