Security
This page describes the protections in place during early access. The full legal description is in the Privacy Policy and on the Security page.
Accounts and sign-in
Section titled “Accounts and sign-in”- Sign-in runs on a dedicated identity service at
auth.weharness.io. - Bot protection. The sign-in and password-reset forms are protected by Cloudflare Turnstile. WeHarness checks each Turnstile result on its servers before it looks at the password.
- Repeated failures. After 10 failed sign-ins, the account is paused for a while before it can be tried again.
- Passwords must be at least 12 characters, and cannot be your email address or username.
- Email verification is required before you can accept an invitation.
- Password-reset links are valid for 30 minutes.
- Registration is closed during early access; accounts come from invitations.
- Two-step sign-in. You can turn it on in Account settings: after your password, sign-in also asks for a code from an authenticator app. You can make recovery codes, each of which signs you in once instead of a code. Every change happens on the sign-in service’s own pages after you sign in again, and removing an authenticator asks for your password and a current code first; WeHarness never sees the authenticator’s secret or your recovery codes. If you lose your phone and your recovery codes, write to info@weharness.io from your address: WeHarness confirms it is you before resetting two-step sign-in, and the reset is recorded.
- Coding tools you allowed at sign-in but that never connected are listed apart in Connect MCP. Sign out everywhere ends them too.
Sessions in the browser
Section titled “Sessions in the browser”- The app never sees your sign-in tokens. They stay on WeHarness servers, encrypted with keys kept apart from the database. The browser holds only a session cookie that scripts cannot read and that is sent only over HTTPS.
- A session ends after 2 hours without activity, and in any case 12 hours after sign-in.
- Every change you make must carry a per-session token and come from the WeHarness site. This blocks cross-site request forgery.
WeHarness staff
Section titled “WeHarness staff”- Staff use a separate panel with its own sign-in, which always asks for an authenticator code. It runs as its own service with its own database permissions, apart from the service your workspace uses.
- Staff see account and usage metadata, not your sessions, source, prompts, outputs, memory or traces. They never join your workspace without the owner’s approval in the app.
- Every staff action is recorded in an audit that cannot be edited: each record is chained to the one before it, so a change shows. Records keep who did what and when, not your content or any credential, and are kept for 365 days.
- Giving the highest staff role, or resetting a staff member’s authenticator, needs two different people.
Workspace separation
Section titled “Workspace separation”Workspace separation is enforced inside the database itself, not only in application code. Every request runs as the signed-in user, and the database returns only rows from workspaces that user belongs to. A query that forgets to filter by workspace still returns nothing from other workspaces.
- Files are checked against their SHA-256 fingerprint on upload.
- Files are stored in a private bucket with no public access.
- Downloads use private links that are valid for 60 seconds.
See Files.
Where data is kept
Section titled “Where data is kept”| Data | Location |
|---|---|
| Application servers and databases | Türkiye |
| Uploaded files | European Union (Cloudflare R2, EU jurisdiction) |
| Project context text and its search index | Türkiye (application database) |
| Network edge and bot protection | Cloudflare global network |
| Search embeddings of accepted project text | Computed by Google (Gemini API); the vectors are stored with the index in Türkiye |
| Code your sessions run, and previews of your app | E2B sandboxes in E2B’s US region |
| Model calls (WeHarness’s replies, plans, and your code’s own calls) | The provider of the model in use; each provider’s locations are on Service Providers and Data Locations |
Project context
Section titled “Project context”Folders and zip files are read in your browser. WeHarness receives only the files its intake policy accepts. Secrets are left out by name and by content, never read on the server and never sent to any provider. Accepted text is sent to Google’s Gemini API only to compute search embeddings. Intake and indexing never execute project files. A disconnected source becomes unreadable at once and is then deleted. See Project context.
Customer code
Section titled “Customer code”WeHarness runs customer code only in isolated cloud sandboxes (E2B), one per job, never inside its own services and never with their credentials. A sandbox ends with its job.
Where a sandbox may connect is enforced outside it, by the provider’s network policy: the package registries installs use, the GitHub hosts dependencies are fetched from, the hosts a few well-known packages download binaries from while they install (Prisma engines, Playwright browsers), and WeHarness’s model proxy. Every other destination is refused, private networks and cloud metadata services included.
WeHarness’s own keys
Section titled “WeHarness’s own keys”- Code in a sandbox never receives WeHarness’s keys. It calls models through a token that works only for that sandbox, with limits on calls and tokens, and ends with the sandbox. WeHarness reads your repository with a GitHub token limited to that repository and valid for an hour; the sandbox gets none.
- The few credentials WeHarness stores, such as a running preview’s access token, are encrypted, bound to their record and short-lived. The keys that encrypt them are rotated without interrupting anyone.
- After every release WeHarness checks that none of its keys appear in logs, container images, the database or the source code.
Automatic protections
Section titled “Automatic protections”- Requests are rate-limited per person, per workspace and per address. Above a limit the answer is
429 RATE_LIMITED, with when to try again. - On a confirmed high-severity abuse signal, new work in a workspace can be paused for up to an hour while a person at WeHarness reviews it (
423 WORK_PAUSED). The answer carries a reason code. Work already running finishes, and you can still read everything. A sign-in that looks unsafe can also be asked to sign in again before new work. A model’s judgement alone never pauses a workspace. - The rules are in section 4 of the Acceptable Use Policy, “Automatic measures and review”.
Coding tools
Section titled “Coding tools”Coding tools connect over MCP with their own sign-in, a token that works only for the WeHarness MCP server, and your role in each workspace. They can never approve anything. Disconnect one in Connect MCP, or all of them with Sign out everywhere. See Sign-in and disconnect.
Reporting a security issue
Section titled “Reporting a security issue”Write to info@weharness.io with “Security” in the subject line.