Security and Trust

Data residency: EU only

Your data is hosted in the European Union. Compute, Postgres, Neo4j, and the evidence store run on Hetzner in Helsinki. CDN, DNS, edge, and object storage run on Cloudflare's EU configuration. There is no routine transfer of your data outside the European Economic Area on the deterministic path.

The paths that can send code-derived context outside the EU today are optional AI features, described precisely below; the deterministic analysis path does not. The full list of infrastructure providers, with locations and status, is on the Sub-processors page.

How your code moves

Our headline claim is "your code stays inside your boundary." Here is exactly what that means, including the honest exceptions. This statement is identical in substance to the data-flow schedule in our Data Processing Agreement.

Here is exactly how your source code moves through Toevan, and where it does not. The three paths below are the whole picture.

1. Deterministic analysis stays in your boundary

The core of the product is deterministic. Indexing, dependency-graph construction, blueprint evaluation, PR gating, and evidence signing all run on Toevan's own EU infrastructure (Hetzner, Helsinki). No third-party AI is involved in any of it. Your source code is processed transiently to produce the analysis and does not leave the Toevan boundary.

2. Optional AI features can send code-derived context to the LLM provider

Several optional AI features can send code-derived context, never your whole repository, to a large language model. Today these are: AI fix generation, which sends the code context for one specific violation; the architecture assistant and chat, which retrieve and send symbol identifiers (names, kinds, signatures, and paths) for the code your question touches; and, depending on configuration, code embeddings during indexing, which turn symbol text (names, kinds, paths, signatures) into vectors.

Today: these code-carrying calls route to OpenRouter, which routes them to Anthropic Claude models hosted in the United States. Code embeddings are the one exception whose destination depends on configuration: the default production configuration runs embeddings on an in-boundary EU model, and only a fallback routes them to the same provider. We state all of this plainly rather than imply code never moves.

Being implemented: all code-carrying calls (fix generation, the architecture assistant and chat, and any embedding calls that would otherwise leave the boundary) will route only to an EU-resident provider (Mistral, Devstral 2) under a zero-data-retention agreement, with no US fallback; if the EU route is unavailable the call fails closed rather than spilling over. Calls that carry no code may continue to use OpenRouter. The zero-data-retention agreement is pending signature; this route is not live yet.

Bring your own key (Team and above): you may configure your own LLM provider key, in which case these code-carrying calls use your own provider relationship, no code-derived context passes through Toevan's routing at all, and each routing decision is recorded in an audit log.

3. Evidence and attestations are yours, and verifiable offline

Evidence records and attestations are SHA-pinned and stored append-only in Toevan's EU store, and the same records are written to a toevan/evidence branch in your own repository, so a copy of the proof always lives where you control it.

Attestations are DSSE-signed with ECDSA P-256 (cosign-compatible) and can be verified offline with toevan audit verify and cosign verify-blob-attestation, with no call back to Toevan. They can optionally be anchored to Sigstore Rekor as hash-only entries: the existence of an attestation becomes publicly checkable, but your code and its content never do. Rekor anchoring is opt-in and off by default.

Encryption

We are precise about encryption rather than claiming a blanket posture.

• In transit. TLS at the public edge, terminated at the load balancer and Cloudflare Tunnel. Internal service-to-datastore encryption is being hardened.
• At rest, sensitive credentials. Credentials are encrypted at the column level with AES-256-GCM. Bring-your-own-key LLM keys use per-credential envelope encryption with a wrapped key-encryption key; OAuth tokens are encrypted with AES-256-GCM.
• At rest, being hardened. Datastore-volume encryption, backup encryption, and encryption of integration secrets are being hardened. We do not claim full-disk or backup at-rest encryption as complete today.

Tenant isolation and access control

Customers share infrastructure with strict logical isolation. We use a shared Postgres schema with row-level organisation (account) scoping enforced on every query, so one tenant's rows are never reachable from another tenant's context.

Authorization is enforced at the request boundary from organisation membership and audited support grants, fails closed, and applies a viewer read-only floor so a least-privileged role can never mutate data. Data erasure is per organisation.

Credential handling

Credentials you give us (for connected providers and bring-your-own-key LLM access) are validated live against the provider before we store them, and are never returned to the browser: the interface shows only a masked last four characters. Bring-your-own-key material uses AES-256-GCM envelope encryption and supports rotation.

Evidence architecture

Evidence is the product. It is built to be tamper-evident and to survive without us.

• Append-only and SHA-pinned. Evidence records are written append-only and pinned by content hash, so a record cannot be silently altered after the fact.
• A copy in your own repository. The same records are written to a toevan/evidence branch in your repository, so the proof lives where you control it, not only with us.
• Retention. The default retention floor is three years. It is a floor, not a ceiling: on Enterprise it is configurable per customer and framework, and DORA-adjacent buyers who need five years or more can set that. Today evidence is immutable and retained for the subscription term; automated retention enforcement (auto-purge at the configured horizon) is being implemented. The full retention schedule is in the DPA.
• Offline verification. Evidence and attestations verify without calling us, using toevan audit verify and cosign verify-blob-attestation.

Supply-chain attestation

Attestations follow open standards so they are portable and independently checkable: in-toto statements, SLSA verification summaries (VSA), and DSSE envelopes signed with ECDSA P-256 and verifiable with cosign. They can be anchored to Sigstore Rekor as hash-only entries, opt-in and off by default.

The point is simple: the proof lives in your repository, not ours, and anyone you share it with can verify it offline.

Error monitoring

We use no external error-tracking vendor. A self-hosted collector (Bugsink or GlitchTip) on our own Hetzner EU infrastructure, with SDK-level scrubbing of source, personal data, and secrets before events are recorded, is being implemented.

Responsible disclosure

If you find a vulnerability, please report it to security@toevan.com. We will acknowledge your report, keep you updated, and will not pursue researchers who act in good faith and avoid privacy violations, data destruction, and service disruption.

Sub-processors and data processing

For the full list of infrastructure providers and their status, see the Sub-processors page. For the contractual data-processing terms, roles, and technical and organisational measures, see the Data Processing Agreement.

Changelog

• v1.0.02026-08-25

  Initial draft: EU data residency, the canonical code-egress statement (deterministic analysis in-boundary, optional per-violation AI fix with the honest OpenRouter/Anthropic current state and planned Mistral EU route, evidence in your repo), precise encryption posture, tenant isolation, credential handling, evidence architecture with a three-year retention floor, supply-chain attestation, self-hosted error monitoring, and responsible disclosure.