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. Your source code and personal data are not transferred outside the European Economic Area on the deterministic path. That path has one outbound flow: the dependency checks described under How your code moves, which send package names and versions to public services in the United States, after Toevan has filtered out the private names it can identify.

Optional AI features are the only paths that can send code-derived context to a third party, and under the EU routing that is enforced by default that context stays in the EU unless you configure your own provider key; the deterministic analysis path sends no code-derived context, and its only outbound lookups are the dependency checks, which carry package names and versions and never source code. 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 four 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 is not sent outside the Toevan boundary. This path does make outbound dependency lookups, described in path 2. They carry package names and versions, never source code.

2. Dependency checks send package names and versions to public services

To check your dependencies for known vulnerabilities and license terms, and to regenerate lock files for fixes you request, Toevan sends the names and versions of the dependencies it reads from your manifests and lock files, except those it identifies as private (see below), to public services in the United States: the OSV.dev vulnerability database, and the public registries and indexes of the ecosystems involved (the npm registry, pub.dev, and, for Go, the module proxy, the checksum database and the pkg.go.dev license listing, and the Python Package Index when Toevan validates the build of a Python project). Each request carries a package name and a version. It does not carry your source code or the contents of your files.

Toevan filters the private names it can identify: before a lookup is made, a dependency is treated as private, and its name is not sent to OSV.dev, the npm registry, pub.dev, the Python Package Index, the Go module proxy, the checksum database or pkg.go.dev, when any of these holds: its Go module path or npm scope belongs to the same GitHub owner as the repository (github.com/owner/... or @owner); it matches a private pattern configured for the platform (the Go GOPRIVATE, GONOPROXY and GONOSUMDB settings and a dedicated pattern list); it resolves from a private registry named in the repository's .npmrc, .yarnrc or .yarnrc.yml, or in a Dart pubspec_overrides.yaml; it is a git, path or local dependency; or it is a Go module path with no domain. When the default npm registry in the repository's configuration is a corporate proxy, no npm names are sent at all. When a package-manager configuration file (such as .npmrc, .yarnrc.yml or pubspec_overrides.yaml) or a go.mod cannot be read, Toevan treats the names of that ecosystem as private rather than guess.

The same filter covers the tools Toevan runs for fixes you request. The Go toolchain is told to treat these names as private, so it does not ask the Go module proxy or the checksum database for them. Lock-file regeneration and build validation for npm, Dart and Python projects are not run when they would name a private dependency to a public registry.

Not checked, and never reported as clear: a dependency that Toevan treats as private is not checked against public advisories, and its license is not looked up in a public registry. The scan says how many were skipped, for example "3 private dependencies not checked against public advisories", and does not show their names. A finding that is already open on such a dependency stays open; it is never marked resolved because the dependency was not checked. Licenses of public dependencies are still looked up in the public registries.

What can still go out: Toevan can only filter what it can identify as private. A private package that none of the rules above recognises, for example a private package under another owner's namespace, with no configured pattern and no private registry in the repository's configuration, looks like a public one, and its name and version are looked up like any other. Source code is never sent. If you need to keep a particular set of names out of these lookups, contact [email protected].

3. Optional AI features can send code-derived context to an EU AI provider

Several optional AI features can send code-derived context to a large language model: AI fix generation, which sends the code context for one specific violation, including when Toevan suggests or opens a fix on a pull request; the AI agents that read your code, such as AI code review, which send the files they read for that task; 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. None of them sends a copy of your whole repository.

Where it goes: these code-carrying calls go to Mistral AI through its EU regional endpoint, under a zero-data-retention agreement, or to your own provider if you configured a key (below). This EU routing is enforced by default at the transport boundary that every Toevan platform AI call passes through: a call that cannot reach the EU route fails closed rather than falling back to a provider outside the EU. Code embeddings run on an in-boundary EU model; under the same enforcement, the fallback that would send embedded symbol text to a provider outside the EU is refused. Mistral may serve a third-party open-weight model on the same EU infrastructure; that model's author receives no data from Toevan and is not a sub-processor.

The US route is on standby: OpenRouter, which routes to Anthropic Claude models in the United States, remains contracted but receives no customer code or code-derived context while EU routing is enforced, which is the production default. It would carry code-derived context again only if that enforcement were switched off.

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 per call, with its route, region and retention status.

4. 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 built in and opt-in per organisation; only record hashes are published.

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. Anchoring in Sigstore Rekor is built in and opt-in per organisation; only record hashes are published.

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. Errors are reported to a self-hosted Bugsink collector on our own Hetzner EU infrastructure. A before-send scrubber strips source code, personal data (including user email and IP address), tokens, and secrets before an event is recorded.

Responsible disclosure

If you find a vulnerability, please report it to [email protected]. 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.

Historial de cambios

• 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.

• v1.1.02026-09-30

  The canonical code-egress statement now states that the EU route for code-carrying AI calls is live and enforced by default (Mistral AI through its EU regional endpoint under a zero-data-retention agreement, or the customer's own provider key, failing closed rather than leaving the EU), that OpenRouter is on standby while that enforcement is on, and lists the AI agents that read your code among the code-carrying features. The data-residency summary no longer says optional AI features send code-derived context outside the EU.

• v1.2.02026-10-23

  Corrects the canonical code-egress statement, which said without qualification that deterministic analysis keeps everything inside the Toevan boundary. It now states that dependency checks send package names and versions to OSV.dev and to the public package registries of the ecosystems involved (including the Python Package Index during build validation of Python projects), that this includes the names of private dependencies until private-name filtering ships, that one lookup (the upgrade-target version index) already filters, and that source code is never sent. The data-residency summary is corrected to match.

• v1.3.02026-10-24

  Private-name filtering now ships, and the code-egress statement says what it does and what it does not. Toevan filters the private names it can identify before dependency lookups: dependencies under the repository's own GitHub owner, names matching the platform's private patterns, dependencies from a private registry named in the repository's configuration, git, path and local dependencies, and Go module paths with no domain are not sent to OSV.dev or the public registries, and no npm names are sent when the repository's default npm registry is a corporate proxy. Skipped dependencies are reported as not checked against public advisories, and a finding already open on one is never marked resolved. A private package that Toevan cannot identify is still looked up. Source code is still never sent. Counsel review required before this version is published as binding.

• v1.4.02026-10-26

  The code-egress statement and the supply-chain attestation section describe Sigstore Rekor anchoring as it ships: built in and opt-in per organisation, with only record hashes published. The earlier wording about its default state is removed. Nothing else changes. Counsel review required before this version is published as binding.