Zephr
Start free

Governance / Privacy mode

Local mode: nothingleaves your machine.

Privacy mode is not a setting that reduces telemetry. It is the whole product running against one SQLite file on your disk, behind a loopback-only gateway, with no account and no sync. This page states exactly what Zephr reads, what it stores, what leaves, and — where a control is specified but not yet built — says so at the same size as everything else.

Shipped · local modeNo account requiredADR-027 · ADR-Z-12On-device embeddings
Local mode— no account required
What Zephr reads

Explicit capture only. There is no background indexer.

Zephr reads what a tool call hands it, and the anchors that claim cites. It does not watch your session, scrape your transcript, or index your disk while you are not looking — because a memory system that captured silently could never tell you where a claim came from.

Reads · on explicit captureVerified

What is read, and when

  • Content an agent or a human explicitly hands to a Zephr tool call

    On zephr_remember — never inferred from a transcript in the background

  • File paths, line ranges, and content digests for the anchors a claim cites

    When a claim is anchored, and again when a cited file changes

  • Git metadata for the admitted worktree — commit SHAs, branch, worktree identity

    On admission, and on every revalidation of the binding

  • The project boundary you approved, and nothing outside it

    Established once by zephr project approve; immutable for the connection

ADR-028 · explicit capture only
Reads · neverOut of scope

What is never read

  • Your terminal scrollback, clipboard, or arbitrary files outside the admitted worktree
  • Environment variables and secret values — Fleet stores references, never values
  • Anything at all when no tool call was made: there is no background indexer in local mode
ADR-017 · secret references, never values
What it stores

One file, and the small set of things that sit beside it.

The full local footprint is enumerable, so here it is enumerated. Knowing the sidecars exist is what makes a deletion claim checkable — and it is why the deletion section further down is honest about which parts are not purged yet.

  • The evidence ledger

    ~/.local/share/zephr/zephr.sqlite

    One SQLite file: beliefs, anchors, provenance edges, review state, revisions.

  • SQLite sidecars

    zephr.sqlite-wal · zephr.sqlite-shm

    Write-ahead log and shared-memory files created by the store at runtime.

  • Signing key material

    ~/.local/share/zephr/keys/<key-id>

    POSIX 0600, owner-checked, exactly 32 bytes. Verified by zephr-mcp key-check.

  • Recovery snapshots

    Beside the store, on demand

    WAL-consistent copies taken under a maintenance lock before migrations.

  • Staged continuity exports

    A local, out-of-store file

    Produced by an explicit export. Retained 7 days by default, then purgeable.

Paths shown are the documented defaults. Source: docs/security/local-privacy-operations.md §6.

Zero egress

In local mode, Zephr makes no outbound network request.

Not a reduced-telemetry mode, not an anonymised mode. The evidence ledger, the signing keys, and the embeddings all stay on the machine that produced them.

The local boundary

What stays, and what the local network surface actually is. The one thing this claim does not cover is stated beneath it — because the exception is the part that matters.

Never transmittedVerified

Stays on your machine

  • Belief and evidence text — the claims, rationales, and everything you captured
  • Source code, diffs, and raw file paths
  • Secret values of any kind (Fleet holds references; the values are never synchronised)
  • Continuity payloads and the signing key material that seals them
  • Review history, reviewer identity, and the provenance graph
SignedEd25519no account · no egress
Local network surfaceVerified

What the gateway actually binds

  • 127.0.0.1 loopback only

    The local gateway binds to loopback. It is not reachable from another host on your network.

  • No account, no signup, no telemetry

    Local mode requires no Zephr account. There is no analytics beacon and no usage ping on this path.

  • No background sync

    Sync is off. There is no scheduled upload and no deferred queue draining later.

127.0.0.1

Illustrative example — not live data. This card describes the documented local-mode architecture; it is not a live network capture.

The exception, stated plainly

Not a Zephr guarantee

Zero egress describes Zephr. It does not describe your coding agent. Claude Code, Cursor, and Codex each talk to their own model provider, and whatever they send is governed by that provider’s terms, not by this page. Zephr not transmitting your ledger does not make your agent local — and implying otherwise would be the most consequential thing this site could get wrong.

Model training

Your content is never used to train a model. No qualifiers.

This is the question that deserves a one-word answer, so it gets four of them — one per way the question is usually asked.

  • Is your content used to train Zephr models?

    No.

    Zephr trains no models. There is no Zephr model to train — the product is a governed evidence store and a deterministic policy engine, not a model vendor.

  • Is your content used to train a third-party model?

    No.

    Every provider on the checked-in allowlist is qualified on contractual zero-training and zero-or-short-retention terms. A provider that trains on submitted content does not get on the list (ADR-027).

  • Could an unknown provider receive it by accident?

    No.

    The allowlist fails closed. A provider that is not on it receives nothing; the call returns a structured provider_unavailable or policy_denied refusal instead of silently falling back to another provider.

  • Does local mode send content to any provider at all?

    No.

    The local lane uses on-device ONNX embeddings (bge-small-en-v1.5-int8). Its allowlist entry is region "local-only" because no data leaves the machine to produce them.

ADR-027 · provider qualification requires contractual zero-training and zero-or-short retention terms before a provider can be listed at all.

Per-project scope

One project at a time, bound for the connection’s lifetime.

A connection admits exactly one project boundary, once, before any tool call. Nothing crosses it: a claim recorded in one worktree is invisible to a session admitted into another, and a connection that never admitted is closed rather than defaulted to something permissive.

Scope · admittedVerified

apps/billing — admitted once, immutable

The binding is established by a human-initiated approval, not by the agent asking nicely. binding_epoch advances by exactly +1 on each legal transition, so a replayed or copied authority is detectable rather than merely unlikely.

Device and inode identity are revalidated on every admission: swapping the directory under a bound path produces a new admission decision, not a silent continuation.

binding_epoch:7Shipped
Scope · foreignscope_violation

apps/internal-tools — never reachable from this connection

The check runs in ToolContext.scope before the tool executes, so a foreign-scope read fails at the transport rather than being filtered out afterwards. Filtering after retrieval would mean the data had already been read.

Foreign-scope exclusion is one of the nine measured TrustBench scenarios, so this is a benched behaviour rather than an architectural intention.

ADR-Z-09 · enforced at the MCP transport

Illustrative example — not live data. ADR-Z-09 · immutable scope binding.

Encryption & key ownership

In local mode, you hold the only key.

Zephr generates the signing key on your machine and never transmits it. There is no escrow, no recovery service, and no copy held anywhere else — which also means a lost key is genuinely lost, and that trade is stated up front rather than discovered later.

Local mode · key postureVerified

Generated locally, held locally

  • Ed25519 signing key generated on the machine, stored at POSIX 0600, owner-checked.
  • zephr-mcp key-check verifies posture — regular file, expected owner, exact mode, exact length — without printing key bytes.
  • No escrow, no recovery service, no second copy. Losing it is losing it.
SignedEd25519Shipped
Managed cloud · key posturePlanned

Per-tenant envelope encryption — designed, not deployed

The cloud design is one KMS master key with a per-tenant DEK wrapped by it; belief content, evidence text, continuity payloads, and exported artifacts are encrypted with the tenant DEK before storage. Account-level erasure crypto-shreds the DEK.

Full KMS key-per-tenant and bring-your-own-key are enterprise options in that design, not defaults — and none of it is in production use, because managed cloud has no public signup.

PlannedADR-011 · no public signup exists
Signed handoff

A handoff you can verify, not a handoff you have to trust.

When you move an evidence bundle between tools or machines, Continuity Format v1 seals it. The receiving side authenticates before it parses — the packet is proven intended for that installation before any of its content is interpreted.

Continuity envelope

Four properties, each independently checkable. A packet failing any one of them is rejected rather than downgraded to a best-effort import.

Slipstream · sealedVerified

Sealed for one destination, once

  • Ed25519 source signature proves which pinned source signed the canonical payload.
  • Destination-bound HMAC-SHA-256 proves the packet was intended for the receiving installation, not merely valid in general.
  • Manifest roots are recomputed from canonical bytes — never trusted from the packet’s own fields.
  • One-time consumption is enforced by an atomic ledger, so a replayed packet is rejected.
Signature validEd25519
Slipstream · rejectedRejected

What a tampered packet gets

Changed content, a copied or mutated packet, a changed operation, session, target, or expiry, and a reused decision are each rejected outright. There is no partial import and no “imported with warnings” path.

Because authentication precedes parsing, a hostile packet never reaches the code that would interpret its contents — the rejection happens before the payload is meaningful.

ADR-Z-14 · authentication before parse

Illustrative example — not live data. The identifiers and digests below are fixture values.

Retention, export, deletion

Leaving is a supported operation. Full erasure is not, yet.

Export is real and shipped: the open continuity format means your ledger is machine-readable and portable. Deletion is where honesty costs something — the primary store file is removed today, and the complete inventory purge is specified but not built.

Retention defaultsVerified

What is kept, and for how long

Your evidence ledger
Kept until you delete it. Zephr expires nothing.
Operation receipts / audit records
90 days after completion, then purged.
Staged export artifacts
7 days after creation, then eligible for purge.
In-flight operation receipts
Never auto-purged — resolved only by crash recovery.
local-privacy-operations.md §8
Deletion · the honest gapPartial

What “delete” removes today

zephr-mcp uninstall complete removes the primary store file after a readiness check and an explicit confirmation phrase. That is what it does, and it is all it does.

It does not yet purge WAL and SHM sidecars, temporary files, caches, staged exports, or OS-held key material. Until the governed receipt, inventory, and key-destruction path ships, calling this full erasure would be a claim without an artifact.

Full inventory purge plannedADR-Z-12
  • zephr-mcp assess --path <store>Shipped

    Read-only readiness assessment of the store. Opens read-only and mutates nothing.

  • zephr-mcp key-check --key <key>Shipped

    Proves key posture — regular file, expected owner, exact 0600, exact 32 bytes — without printing key bytes.

  • zephr-mcp continuity exportShipped

    Writes your ledger to the open continuity format. Machine-readable, so leaving is possible.

  • zephr-mcp uninstall completeShipped · primary store file only

    Removes the primary store file after a readiness check and an explicit confirmation phrase.

  • delete_installation (full inventory)Planned · specified, not built

    The complete purge — WAL/SHM sidecars, temporary files, caches, staged exports, and OS-held key material — recorded by a durable receipt written before any destructive commit.

Human access

Nobody at Zephr can read a local ledger — architecturally, not by policy.

A policy commitment is a promise. An architecture is a constraint. In local mode there is no account, no upload path, and no service that could be compelled to hand your ledger over, because we never receive it.

  • No Zephr employee can read a local-mode ledger

    Shipped · local mode

    Not as a policy commitment — as an architectural fact. The file is on your disk, the gateway is loopback-only, and there is no account linking it to us.

  • Privileged local actions require peer-credential authentication

    Planned · ADR-Z-12 spec

    SO_PEERCRED proves the peer user for revocation, rebind, and privacy operations. It proves the user, not the process — see the residual below.

  • Same-UID process isolation

    Open residual

    An open residual, stated plainly: stock POSIX does not isolate two processes running as the same user. Another program running as you can reach the same files you can.

Model providers & subprocessors

A checked-in allowlist. Unknown providers fail closed.

Provider calls are treated as subprocessed data processing, not as an internal implementation detail. The allowlist lives in the repository, so its contents are reviewable by anyone — including the fact that the only enabled entry today is the on-device one.

Provider allowlist: training terms, retention, regions, and enablement
ProviderTrainingRetentionRegionsStatus
Local ONNX Runtime (BGE)The default. Embeddings are computed on your machine; nothing is transmitted.nonenonelocal-onlyEnabled by default
OpenAI via litellm proxyDisabled in the checked-in allowlist. Requires explicit organisation opt-in, and may never receive source code or belief capsules.nonenoneus-east-1 · eu-west-1Disabled — opt-in required

Never sent to any hosted provider

  • Source code and diffs
  • Raw file paths
  • Secrets of any kind
  • Continuity payloads
  • Unredacted external-user PII

There is no provider fan-out: a request goes to the one selected allowed provider, and evaluation experiments using your data require separate explicit consent. Provider events record the model, region, prompt digest, and policy decision — never the prompt or response content.

Source: packages/provider-allowlist/provider-allowlist.json · ADR-027. Updating the list requires a security review and a review-date bump.

Prompt injection & poisoned memory

A memory store is an injection surface. Here is what actually defends it.

Text an agent captured can contain instructions aimed at the next agent. Zephr's defence is structural rather than filter-based: nothing is trusted because it is stored, and the one control that would require model judgement is honestly marked as not built.

  • Provenance is required before a claim carries weight

    Shipped · ADR-Z-08

    A memory with no source is recorded as an unanchored opinion, not as a fact. Injected text that cites nothing inherits no authority.

  • Human review is a separate, attributable step

    Shipped

    Capture never confers trust. A claim reaches reviewed state only through a human decision that is recorded and dated, so poisoned memory cannot promote itself.

  • Contradiction abstains rather than resolving

    Shipped · TrustBench scenario

    When a planted claim disagrees with a reviewed one, recall returns the contradiction. It does not silently prefer the newer or the more confident-sounding text.

  • Foreign-scope exclusion

    Shipped · TrustBench scenario

    Claims from a scope you did not admit are excluded from recall. A poisoned repository cannot reach across a binding boundary.

  • Prompt-injection containment for model-assisted judgement

    Not evaluated · T3 deferred

    Listed as a precondition for T3 judgement in ADR-Z-07 — and T3 is not built. There is no shipped control here, and no measured resistance to report.

ADR-Z-07 lists prompt-injection containment among the preconditions for T3 judgement. T3 is deferred, so no measured injection-resistance result exists to report.

Exclusions you control

Exclusion is the default. Inclusion is the explicit act.

You do not opt out of Zephr reading things; you opt in, one project at a time. These are the levers that decide what is even reachable.

  • Project boundary

    Shipped · ADR-Z-09

    Only approved projects are admitted. A path you never bound is unreachable — the exclusion is the default, and inclusion is the explicit act.

  • Worktree-scoped policy

    Shipped · ADR-Z-08

    Trust Firewall rules are configured per worktree: capture limits, required provenance, permitted review states, contradiction handling.

  • Hosted embeddings off

    Shipped · ADR-027

    The local ONNX lane is the default and the documented fallback. Hosted embedding providers stay disabled until an organisation explicitly opts in.

  • Per-repository hosted-code policy

    Planned · managed cloud

    Source-code chunks reach a hosted provider only where an organisation, project, and repository policy all explicitly enable it for that provider, region, and model.

The same ledger, with the network removed.

Local mode is not a reduced product. Capture, signing, verification, and review all work unchanged — what you give up is cross-machine sync and shared team memory, and we say so before you install.

Read the docsSecurity controls