Synthetic illustration

See what a control decision looks like.

A useful rollout review connects a policy, a test and a recorded result. This example shows the structure of a Toren hook decision and the context a security reviewer can inspect.

Illustrative data only. These two records were constructed to explain the format. They are not from a customer or deployed endpoint, and do not demonstrate validated security effectiveness.

Download sample JSON Download JSONL

What a reviewer can learn

The decision: the second record illustrates a denied read in the cloud-credentials category, associated with control H-11.
The context: the timestamp, session and tool identify the event to correlate with a test. Control, threat and flow identifiers connect it to the review materials.
The next question: compare the decision with the test result, policy version and endpoint configuration. A recorded denial alone does not prove that every route to the same resource is blocked.

synthetic-evidence.jsonl · record 2 of 2

{
  "schema_version": "1.0",
  "timestamp_utc": "2026-09-01T00:00:01.000000Z",
  "hostname": "synthetic-endpoint",
  "session_id": "synthetic-session-001",
  "cwd": "/synthetic/workspace",
  "permission_mode": "plan",
  "hook_event_name": "PreToolUse",
  "tool_name": "Read",
  "tool_use_id": "synthetic-tool-use-001",
  "repository_id": "synthetic-repository",
  "action_category": "cloud_credentials",
  "decision": "deny",
  "reason": "Cloud credentials grant privileged infrastructure access (out of pilot scope).",
  "control_ids": [
    "H-11"
  ],
  "threat_ids": [
    "T-04",
    "T-12"
  ],
  "flow_ids": [
    "L-D2",
    "L-D8"
  ],
  "hashed_input": null,
  "redaction_status": "n/a",
  "evidence_source": "PreToolUse",
  "correlation_id": "synthetic-session-001",
  "change_ticket_id": null,
  "prev_hash": "3d7bf3fbd9845a70020a43ad97a63dd5889d91e3c28b1a9fb2b63e32541b6e4e",
  "record_hash": "1b62a99ed7cad5cfbe60fececa1c8274efa4c2530807064d0980804e539f2d43"
}

The downloads contain both records, full hashes and valid JSON without comments. Every endpoint, session and repository value is synthetic. The sample uses the current hook record fields; deployed fields and collection requirements should be reviewed during scoping.

From a log entry to a rollout decision

Use a pilot to agree the controls and scenarios that matter to your business. Review the results alongside deployment checks, exceptions, known limitations and evidence handling. This gives your security and risk teams a concrete basis for deciding whether to expand, adjust or pause a rollout.

Metadata still needs care: the record format can include a hostname, working directory and session identifiers. This example contains no source code, file contents or secrets. Review the actual fields, retention, access and forwarding configuration before collecting production evidence.

How the sample hashes are verified

The JSONL file uses the same chain calculation as the hook evidence writer. The JSON download is an array of those same records.

Start with the seed TOREN-EVIDENCE-CHAIN-V1. Each record’s prev_hash must equal the seed for the first record, or the preceding record’s record_hash.
Remove record_hash from a copy of the record; keep prev_hash. Serialise with Python json.dumps(record, sort_keys=True, separators=(",", ":")), using its default ASCII escaping.
Concatenate the previous hash string (or seed) with that serialised JSON. SHA-256 the UTF-8 bytes and compare the hexadecimal digest with the stored record_hash.

The expected final record hash for this two-record illustration is:
1b62a99ed7cad5cfbe60fececa1c8274efa4c2530807064d0980804e539f2d43

What this proves: a successful check shows internal consistency with that calculation. It does not authenticate the endpoint or establish that the recorded event happened. Changing indentation or JSON key order does not change the digest because records are parsed and serialised again.

What it cannot prove alone: someone able to rewrite a local log can change records and recompute the chain. Removing the end of the log can also leave a valid shorter chain. To detect those changes, compare the expected record count and final digest with a previously retained, trusted reference outside the attacker’s control. The digest on this page is a convenience for checking the sample, not independent custody of production evidence.

Configure and validate protected evidence collection, forwarding and retention for your deployment. Hash chaining on its own does not provide completeness, digital signatures or independent assurance.

Request a demo Explore deployment requirements