No compliance badges
Zephr does not claim SOC 2, ISO 27001, HIPAA, GDPR certification, or any other third-party attestation. When an audit is completed, the report will be linked here — not a logo.
Use cases / Enterprise
When the reviewer asks,the answer exists.
Someone will eventually ask what your coding agents were allowed to read and what they wrote back. The primitives that answer that are shipped in local mode today: authorization before retrieval, immutable scope binding, a receipt per operation. The org-level controls above them are planned, and named as such.
Primitives shipped · Org controls plannedauth-before-retrievalimmutable scopeaudit receipts
consent receipt · operationrecorded
- operation
- zephr_remember
- scope
- payments-api · worktree main
- admitted at
- connect time · immutable for the session
- policy
- passed before retrieval
- review state
- pending → confirmed (human)
the receipt is the answer — not a summary written later
Illustrative example — not live data
The problem you actually have
A reviewer asks a question the tooling cannot answer.
Three months into rolling out coding agents, someone from risk asks what a particular claim rests on and which repositories the agent could see when it made it. The honest answer is that nobody can reconstruct it: each editor kept its own private summary on one laptop, the rules were a file the tools may or may not have read, and the session that would have explained it closed weeks ago. What follows is not a finding, it is a fortnight of people reading chat logs to assemble an answer that is itself unverifiable. Three specific gaps produce that outcome, and none of them is fixed by writing more of them down after the fact.
- No provenance
- Decisions are remembered as opaque summaries. When a reviewer asks what a claim rests on, there is nothing to traverse.
- No audit trail
- What the AI read, wrote, or approved is trapped inside one client on one machine, and evaporates when that session closes.
- No enforced policy
- Project rules live in advisory files. Enforcement depends on whether each tool chose to read them, which is not a control.
The evidence packet
Ask the reviewer's questions.
Six questions a risk reviewer will actually ask. Each answer names whether the shipped local primitives answer it today or whether it requires the managed cloud — and points at the real ADR or receipt contract that proves it.
the reviewer asks
What was the agent allowed to read when it made this claim?
The admitted scope at connect time — immutable for the session. The scope binding records exactly which worktree and which surfaces the connection held.
ADR-Z-09 · immutable scope binding
answerable todayillustrative — every evidence reference points to a real ADR or shipped behavior
How it works for a governed team
Admit the scope. Evaluate the policy. Keep the receipt.
Authorization happens before retrieval, so the question of what an agent was allowed to see is settled before anything reaches a prompt. Each of the three steps leaves an artefact a reviewer can read, and all three are shipped and run locally. Order is the whole design. A check that runs after retrieval can only decide whether to show you something the model has already read, which is a filter rather than a control, and no amount of logging turns one into the other.
- 01
Scope admission
Every connection is bound to an explicitly approved project, repository, and worktree. A scope change is a new admission, not a mutable field on the session.
- 02
Policy evaluation
The Trust Firewall evaluates policy before retrieval or capture — never after. Refusals are specific enough to act on, which is what makes them auditable.
- 03
Receipt chain
Every operation produces a durable receipt scoped to digest, operation, identity, and timestamp. The audit trail is a by-product of the request path, not a separate logger.
zephr audit export --scope payments-api --format json- Admitted write
- A write into the project this connection was admitted to at connect time. It lands, and it leaves a receipt.
- Refused write
- A write aimed at a project this connection never held. It stops at the boundary before anything is read or stored.
out_of_scope · hr-platform
The refusal names the scope that was asked for and the scope that was held. A reviewer reading it later can tell what was attempted, which is the difference between a control and a silent drop.
Illustrative example — not live data
What applies to you
Four of these run today. Four are designed and not built.
Even in local mode Zephr ships the primitives that organization governance would scale: the policy engine, immutable scope binding, consent receipts, and honest abstention. The shipped four come first, and the four controls above them are marked as what they are.
Trust Firewall policies
ShippedDeterministic, worktree-scoped policies gate both capture and retrieval. A refusal names what was missing rather than returning a generic block.
policy engine · Guard cluster
Immutable scope binding
ShippedProject, repository, and worktree are admitted once and bound for the lifetime of the connection. Changing scope requires a newly admitted connection, not a parameter.
ScopeSnapshot · binding_epoch CAS
Per-request consent + audit receipts
ShippedEvery read and write carries explicit consent and produces a durable receipt scoped to digest, operation, identity, and timestamp.
receipts as durable objects
Honest abstention
ShippedBelow the confidence bar the system returns a typed abstention naming the gap, rather than assembling a plausible sentence from fragments.
honest-or-absent law · ADR-016
Organization-level controls
Planned (managed cloud)Organization-wide policy, project admission gates, and role-scoped permissions above the per-worktree primitives.
gated on the ADR-010 tenancy gate
Team-scoped policies
Planned (managed cloud)Rules that travel with the project rather than with one user or one advisory file, enforced identically for every connected client.
designed; not built
Audit export
Planned (managed cloud)Long-form evidence ledger and action history exported for compliance review, rather than read one receipt at a time.
designed; not built
Data residency options
Planned (managed cloud)Tenant-level control over where source, evidence, and derived indexes are stored and processed.
gated on the ZEP-1 security review
Shipped primitives run locally. Organization-level scaling requires the managed cloud and a security review that has not yet passed.
The daily loop
What changes when the reviewer comes back.
The question stops being a research project. What an agent was permitted to see was decided at admission and cannot have drifted since, every read and write left a receipt, and a claim that could not be supported was refused with the reason attached rather than answered anyway. Your developers do not do anything extra to produce that trail. It falls out of the request path, which is the only version of an audit trail that survives a busy week.
Honest boundaries
What is not claimed.
Zephr does not market certifications, scores, or readiness that do not exist. This section is a public commitment to that boundary, and it is meant to be held against us. If you are evaluating a tool whose job is to tell you when it does not know something, the first evidence you have is whether its own marketing page will do the same.
Not claimedNot held Not claimedNot held No customer logos
There are no external design partners or customer references on this page, because there are none to reference.
Not claimedNot held No ROI promises
No savings figures, velocity gains, or risk-reduction numbers are stated, because none have been measured. TrustBench publishes what has.
Read the security model.
The trust page covers the TrustBench suite, the Trust Firewall, scope binding, and the evidence chain in detail — each linked to the source document rather than summarised.