Evidence locker

An evidence locker is the sealed record of one engagement: the artifacts the agent captured, in the order it captured them, bound into a hash chain, described by a manifest, and signed with your organization's Ed25519 signing key.

A report states what the agent found. A locker holds the material the report was written from, in a form a third party can recheck: recompute each artifact's hash, recompute the chain, verify the signature. That check runs on the recipient's machine, against a zip, with no Pentr account and no network access. The report and the locker come out of the same run and are exported separately.

The marketing account of all this is on the Evidence locker page. This section is the mechanism.

How a locker is made¶

1. Capture. The agent hashes each piece of evidence with SHA-256 at the moment it is produced and streams it to the server, which stores the bytes under that hash. See Artifacts.
2. Chain. When the run completes, the artifacts are ordered by their position in the run and hashed into a linear chain. Each entry's hash covers the previous entry's hash, the artifact's own hash and the entry's metadata. The last one is the chain head. See The hash chain.
3. Sign. A manifest records every entry, the chain head, the entry count, the framework and a digest of the scope and rules the run was authorized under. A signature block carrying that manifest's hash is then signed with the organization's active key. See Sealing and Signing keys.
4. Export. A sealed run can be packaged as a zip holding the manifest, the signed bytes, the signature, the public key, a seal summary, a README and every sealed artifact. See Exporting a locker.

Steps 2 and 3 happen once, automatically, when a run ends and returns results. There is no re-seal path, so a run that crashed or whose seal attempt failed stays unsealed.

What a seal establishes¶

A locker that verifies tells the recipient three things: no sealed artifact's bytes have changed since the seal, the artifacts are in the order they were sealed in, and the run was authorized under the scope and rules the manifest digests. If the recipient pins a public key they obtained from you independently, it also tells them your organization's key produced the signature.

It does not tell them when the run happened — signed_at is the platform's own clock, self-asserted, with no trusted timestamp — and it does not tell them the test was thorough or the findings correct. A run stopped at a step ceiling, and a run rejected for a bad scope before it captured anything, are both sealed the same way; the manifest's entry count is what distinguishes them, not the seal. The private key is held by Pentr, encrypted at rest, so the platform is technically capable of signing on your behalf. What verification does not prove is the full account.

The pages in this section¶

Five pages describe how evidence is made:

• Artifacts — what gets captured, what it records, and the size ceiling.
• The hash chain — the chain, the manifest, and the canonical encoding both depend on.
• Signing keys — generating, uploading and rotating the key, and where the private half lives.
• Sealing — when a run is sealed and when it is not.
• Exporting a locker — the HTTP call and the contents of the zip.

Three are written for the person who receives a locker rather than the person who produced it, and assume no console and no account:

• Verifying a locker — running pentr-verify and reading its output.
• Share links — the recipient's side of a link: what the share viewer shows them, what it leaves them to check, and how expiry and revocation end their access. Creating a link is covered in your first engagement.
• What verification does not prove — the limits of a passing check.