Security

How we protect your code.

Last updated: 2026-07-25

Tavsin's strongest security property is architectural: by default, your code, project memory, intelligence graph, and traces never leave your machine. This page describes what we do, how the agent is constrained — and, in plain terms, what we do not yet claim.

Doing vendor diligence? Everything below is written to be checkable. If a question isn't answered here, email security@tavsin.xyz and we'll answer directly rather than point you at a brochure.

1. Architecture: local-first by default

The desktop app and CLI keep every artifact in a SQLite database inside your own project directory (<project>/.tavsin/project.sqlite). There is no telemetry, no analytics ping, and no usage tracking. With a local model endpoint configured, Tavsin works fully offline.

This means the common SaaS breach question — "what happens to our source code if your servers are compromised?" — has a structural answer for local use: we never had it.

When data does leave your machine

Model providers. When you use chat or agents, the prompt (which may include file contents you or the agent attach) goes to the model provider you configured — Anthropic, OpenAI, Google, OpenRouter, or a local/self-hosted endpoint. Choosing the provider is yours; Enterprise can bring its own endpoint so prompts never reach a third party.
Hosted workspace. If you use app.tavsin.xyz, project data for that workspace is stored on our infrastructure (below).
Account & billing. Email, authentication material, and subscription state.

The full breakdown, including our processors and AI sub-processors, is in the Privacy Policy.

2. Infrastructure & data residency

Hosted workspace	Runs on infrastructure located in Germany (Hetzner) — EU data residency for workspace data.
Marketing site	Static assets via Vercel's edge (multiple regions). No customer data.
Tenant isolation	Each account's project data lives in its own SQLite database, not a shared multi-tenant table.
Transport	TLS for all traffic, with HSTS enforced.
Backups	Encrypted, versioned snapshots of the hosted workspace (restic).

3. Application security

Password storage. scrypt with a per-server salt; verification is constant-time, and login compares against a dummy hash for unknown accounts so response timing can't be used to enumerate who has an account.
Sessions. Opaque, server-side, and revocable. Cookies are HttpOnly, Secure, and SameSite=Lax. A password reset revokes all existing sessions.
OAuth sign-in. The state parameter is CSRF-checked against an httpOnly cookie, and a single-use handoff code is used so the session token never travels in a redirect URL.
API authentication uses a bearer header rather than cookies, so the JSON API is not CSRF-exposed.
Rate limiting on login, signup, and password reset.
Response headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
Outbound requests from the server (e.g. a custom model base URL) pass a fail-closed SSRF guard that resolves DNS and refuses private/link-local ranges.
Server errors are redacted before they reach a client.

Secrets

On the desktop app, provider API keys, connector tokens, and license keys are encrypted at rest using the operating system's keystore (Keychain on macOS, DPAPI on Windows, libsecret on Linux) rather than stored as plaintext. Model-call audit records never contain API keys.

4. Payments

Billing runs on Stripe. We never see or store card numbers. Stripe webhooks are verified by HMAC signature over the raw request body and are idempotent, and the subscription tier of record is set only by that verified webhook — never by the client.

5. Agent guardrails

An autonomous coding agent is a security surface in its own right: it reads files and runs shell commands. Tavsin enforces guardrails deterministically at the tool-execution layer, not by asking the model nicely in a prompt — because weaker models ignore prompt instructions.

Command policy. Every command is checked before it runs. Catastrophic operations (disk wipes, fork bombs, piping the internet into a shell) are refused at any autonomy level. Destructive-but-sometimes-intended operations (force-push, hard reset, DROP TABLE, infrastructure teardown, package publish) are refused unless you explicitly opt into unattended runs.
Credential protection. Reads of private keys and cloud-credential stores are refused, and commands that pair a local-data read with network egress (pipes, redirects, command substitution, upload flags, DNS exfiltration, remote copy) are blocked.
OS-level sandbox. On macOS, agent shell commands run under a seatbelt profile that denies reads of credential stores at the kernel level — so even an unrecognized command has nothing to steal.
Filesystem boundary. File tools are confined to the project directory, with symlinks resolved and hard-linked files refused so neither can be used to reach outside it.
Network egress allowlist (opt-in) confines agent HTTP(S) traffic to an allowlist of package registries and git hosts.
Verification & rollback. The agent cannot report a change as done until a real check passes; if a check fails, its edits are rolled back rather than left in a broken state.
Audit trail. Every meaningful action is recorded as an append-only trace you can inspect.

Honest scope: the command policy is defense-in-depth, not an impassable boundary — a denylist can always be probed. The OS sandbox is currently macOS-only, and the egress allowlist routes proxy-aware traffic but is not yet backed by kernel-level network isolation on every platform. We are building that; we would rather tell you than let you discover it.

6. Your controls

Export. Download everything associated with your account as JSON.
Deletion. Delete your account and its data. Deletes inside a project store are tombstoned so audit history stays complete; a hard purge is available and refuses to run against live rows.
Memory review. Every learned memory is inspectable, correctable, and deletable — nothing is silently retained about your codebase.
Audit log. Authentication and account events are recorded with timestamp and IP.

7. Reporting a vulnerability

Email security@tavsin.xyz. Please include reproduction steps and give us a reasonable window to remediate before public disclosure. We will acknowledge, keep you updated, and credit you if you'd like. We do not currently run a paid bounty programme.

8. What we do not claim yet

Security pages are easy to pad. These are the things a careful buyer will ask about that we have not completed:

SOC 2: not certified. We are working toward it; we will not describe ourselves as compliant until a report exists.
ISO 27001 / HIPAA / FedRAMP: none held.
Third-party penetration test: not yet commissioned. Our security work to date is internal review and adversarial self-testing.
SAML SSO and SCIM provisioning: not yet available. Sign-in is email/password or OAuth today. These are on the Enterprise roadmap — ask us about timing.
24/7 monitored SOC: we do not operate one.

If any of these is a hard requirement for your organisation, tell us before you buy rather than after — enterprise@tavsin.xyz.

9. Enterprise agreements

Enterprise plans include a signed Data Processing Agreement, a security review with our team, and options for on-premises or VPC deployment where no data reaches our infrastructure at all. Contact enterprise@tavsin.xyz.