Security

Report a vulnerability

Email [email protected]. Please include:

• what is affected (URL, endpoint or client and version);
• the steps or proof of concept to reproduce it;
• the impact you believe it has;
• how you would like to be credited.

We acknowledge reports within 3 business days, keep you informed, and agree a disclosure date with you once a fix is available. For the open-source clients you can also use private vulnerability reporting on the project's GitHub repository. A machine-readable contact is at /.well-known/security.txt.

Safe harbour

We will not pursue legal action for research that follows this policy:

• test only against accounts and workspaces you own, or with the owner's explicit permission;
• do not access, change or delete other people's data — stop and tell us if you reach any;
• do not degrade the Service (no denial-of-service, spam or brute-forcing at volume) and do not use social engineering or physical attacks;
• give us reasonable time to fix before any disclosure.

Out of scope: findings from automated scanners without a demonstrated impact, missing security headers without an exploit, clickjacking on pages without sensitive actions, rate limits on non-sensitive endpoints, and self-XSS.

How we protect your account

• Sign-in. Passwords are at least 15 characters and hashed with Argon2; Google sign-in is optional. Browser sessions are HttpOnly, Secure cookies with a CSRF token; CLI and Desktop use 10-minute access tokens with rotating refresh tokens, and reuse of an old refresh token revokes the whole sign-in.
• Secrets shown once. API keys, router keys, session tokens and attach tickets are stored hashed. A plaintext secret is shown exactly once and can be rotated or revoked at any time.
• Devices. Every browser and native-client sign-in is listed under Devices, where you can revoke it. A password reset signs out every session.
• Audit trail. Sign-ins, key and device changes, workspace lifecycle events and every billing adjustment are recorded in an append-only audit log.

How we isolate workspaces

• Each workspace runs on its own virtual machine with its own encrypted volume.
• Clients reach a workspace only through the attach gateway, with a short-lived ticket that names that workspace; the gateway strips cookies before forwarding.
• Secrets you give agents — SSH identities and environment values — are encrypted at rest and only delivered to the workspace that uses them.
• Agents act with the permissions you configure. Haarness permissions are application-level policy, not an operating-system sandbox: an approved command runs with the workspace's privileges, inside that workspace's machine.

What we log

Each request to our API, attach gateway and model router writes one log line: the method, the route pattern (such as /api/v1/workspaces/{id}, never the actual path with its identifiers), the status, the duration and a request identifier — never IP addresses, query strings, headers (including authorization headers and cookies), request or response bodies, payment details or secret values. Error messages from Stripe, Google and Fly are cut short and stripped of email addresses and credentials before they are logged or stored, and service-email logs show only the kind of message and a masked address. Metering records count tokens and cost, never prompt content.

Payments

Card details are entered on Stripe's hosted checkout and never reach our servers.

See also: Privacy policy · Subprocessors · Data processing agreement · Trust boundaries