Glossary

The vocabulary of execution evidence

Twelve key concepts, defined in plain terms, so security, platform, and compliance teams talk about the same objects: records, verdicts, coverage.

Seal bundle: A self-contained export of a slice of an evidence stream, in the .seal format: records, checkpoints, signatures, certificate chain, timestamp tokens, manifest, and verification instructions. It is the artifact you hand to an auditor, a regulator, or opposing counsel — and it verifies offline, with nothing asked of Sealr.
Checkpoint: A signed statement the Recorder emits at least every thousand records or every ten seconds. It seals the Merkle root of the records since the last one, together with the current chain head. The Console countersigns it after validating monotonicity, which makes a history rewrite carried out with a stolen recorder key detectable.
Coverage gap: An interval during which operations could have executed without being recorded: Recorder stopped, an uninstrumented surface, a saturated local spool, a guard failure. Those intervals become signed records in their own right — starts and stops, spool shedding, clock anomalies, reconciliation misses against GitHub events — so their extent can be bounded. Coverage remains a deployment property, not a product promise.
Evidence stream: The ordered, append-only sequence of records produced by a Recorder: every intercepted operation, every verdict, every approval, every lifecycle event. The stream proves the integrity, ordering, timing, and origin of what was recorded. It says nothing about what was not.
Exposure Report: The findings drawn from the customer's own traffic, generated thirty days after install and monthly thereafter: how many operations the agents executed, how many were destructive against production resources, how many are traceable to no human principal, where coverage gaps sit, and a simulation of the verdicts that would have applied in enforce mode. The numbers do not come from Sealr; they come from the records.
Hash chain: The cryptographic link binding each record to the one before it: the previous record's digest is carried inside the next, then sealed by a signature. Any insertion, deletion, or reordering breaks the chain and shows up at verification. The chain makes tampering evident; it does not prevent it.
Merkle root: A single digest summarizing a set of records arranged as a tree. It lets you prove that one specific record belongs to a checkpoint without disclosing the others, and it compresses an entire day of evidence into one value — the value that gets timestamped.
Non-human identity (NHI): Any digital identity that does not belong to a person: service account, API key, certificate, workload, AI agent. These are the identities operations execute under, and therefore the subjects attached to each record. Inventorying them, managing their lifecycle, and rotating their secrets is what posture products do; Sealr confines itself to proving what they executed.
Observe mode and enforce mode: The two regimes a policy can run in. In observe, verdicts are computed and recorded but never applied: the operation proceeds. In enforce, a BLOCK stops the operation and a REQUIRE_APPROVAL holds it until a human decides. Every new resource starts in observe, and every mode change is itself recorded.
Qualified eIDAS timestamp: A token issued by a qualified trust service provider under the eIDAS Regulation, attesting that a piece of data existed at a given moment and carrying, on that basis, a presumption of accuracy in EU law. Sealr anchors checkpoint digests to an RFC 3161 authority continuously, and obtains a qualified timestamp on the daily consolidated root.
Recorder: The Rust binary installed on the customer side, in the execution path of agents: MCP proxy (stdio and HTTP), agent hooks, CLI wrapper. It evaluates the guards and writes records locally without waiting on the network, and keeps working when the Console is unreachable. By default only metadata and cryptographic commitments leave the host: payloads stay with the customer.
Verdict: The decision a deterministic guard returns before execution, derived from the operation itself — the statement parsed with a real PostgreSQL grammar, the Terraform plan JSON, the git arguments — never from the prompt. Four possible values: ALLOW, WARN, REQUIRE_APPROVAL, BLOCK. The decision is made locally in single-digit milliseconds, carries its reason codes, and becomes a record in its own right.

Missing a term?

This glossary tracks the evidence format, which is open and independently verifiable. Browse our guides and resources to dig deeper, or talk with a solutions engineer during a demo.