How ZIFFER fits your stack

Four zones. The line that matters is the first one: the executor stays with you, and it is the executor that refuses to act without a valid receipt.

  YOUR ENVIRONMENT              │  ZIFFER                  THE APPROVERS

  agent                         │                          their own devices,
    │                           │                          their own keys
    ▼                           │                               │
  SDK or MCP server ─proposal───┼─▶ policy engine ◀─attestation──┘
                                │     │ grades against your signed policy
  executor ◀────────receipt─────┼─────┤ receipt signed by a key in a KMS
    │ verifies, then acts       │     │
    ▼                           │     ▼
  your systems                  │   append-only ledger ─▶ audit chain
  your credentials, never ours  │                            │
                                │                            ▼
                                │                        THE ANCHOR
                                │                        published where a
                                │                        third party can read it

Your environment into ZIFFER

What crosses is the proposal, and an API key that says which tenant you are.

Nothing else crosses. The values the decision turns on are not read from the proposal at all: the grade, the reversibility class and the sensitivity of each target are recomputed on the deciding side from the policy bundle you signed. The tenant is the key's, so a proposal body naming a different tenant is refused rather than quietly rewritten, and the door restamps the fields it owns rather than trusting your copies of them. The deployment specification puts the model and anything that translates for it in the untrusted zone: no component there may hold a key that signs anything.

ZIFFER back into your environment

What crosses is the receipt. What verifies it is your executor, in your own process.

It checks the signature under the trust anchor you obtained out of band, not one fetched from the service being checked. Every signature primitive must verify, never any one of them. It recomputes the proposal hash from the bytes you hand it and compares that against the receipt's, because a transmitted identifier is a name for a binding and not evidence of one. And it checks the receipt's validity window against your clock, not against a time the message supplied.

ZIFFER and the approvers

What crosses is a signed attestation from each approver, coming back in.

The approver's private key never leaves the approver's device. No component of the control plane may hold, escrow, proxy or recover it, and the deployment specification requires the deployment to write down where each one lives. It also puts the operator outside the approval zone for anything they proposed themselves: one credential that can both raise a proposal and sign for it satisfies the distinctness rule on every single decision and defeats it in aggregate.

ZIFFER and the anchor

What crosses is a commitment to the receipt chain, published outward.

The party that verifies anchors and the party that reconciles the chain both sit outside production, and the deployment specification requires that neither holds any credential valid inside it, including read credentials on the audit database. A reconciliation job that runs outside production but authenticates into it with a production service account has satisfied the sentence and not the reason for it: its credential is exactly what a production compromise obtains.

Your environment and your systems

Nothing of ours crosses this boundary at all.

ZIFFER holds no credential to any system you can affect. Only your executor holds them, and that is what makes a verified receipt the single route to an effect. Note what this does not mean: your systems verify nothing. No clause anywhere asks a payments API or an ERP to check a receipt, and the guarantee is entirely upstream, resting on the executor being the only holder of the credentials.

One property of the control plane is worth naming because it is easy to state too strongly. The receipt signing key is the only application-layer signing key inside it. That is why a compromised executor cannot mint a receipt. It is not the same as saying the control plane holds one key: every service there holds a transport credential, because every link between them is mutually authenticated.

What this drawing does not show

Absence is legible in a list and invisible in a diagram, so the limits are stated rather than implied.

• No network mechanism. Firewalls, service meshes and egress proxies are deployment choices, and the deployment specification names credentials and hosts instead.
• No replica count, no failure domain, no tenancy multiplicity.
• No behaviour of a component that is starting, restarting or degraded.
• No evidence that any real deployment is isolated. The record a deployment writes about itself is read by auditors and by nothing at runtime, and no test in any repository could observe a host or a credential domain. The specification says so about itself: the number of clauses in that section with an executable consumer is zero.

Stamped against the specification at engine commit d0a176597a70e4b892ecef23da1e210512472bce, published at github.com/ziffer-hq/ziffer-spec.