sha3:aa8f5808d30bc79f0fb96e80923fc035788c0b8204be9d1405f0de40e8e64d4dIntactPROOF LAYER 02 / CHANGE
The change happened at 02:14. The question is whether the record of it can still be edited at 09:00.
sha3:6b028eba85bfIndependently verifiable60d850c9f7c3308e641fa5124c04df3d695272299dd7a7cc18dec165021e1097prev:93409bd0a0b8An agent changed something overnight. Produce the record.
Q1Who or what changed it?
Q2Under what authority?
Q3Can the record of the change be edited after the fact?
At 02:14 UTC something modified an inbound rule on a production security group. By morning you owe your AO three answers, in order: who or what made the change, what authority permitted it, and whether the record you are about to hand over has been altered since it was written.
Most organizations can answer the first from activity logs. Some can answer the second, if approvals live somewhere findable. Almost none can answer the third, and the reason is structural: in most architectures the audit trail is a table in a database, and anyone with administrator rights on that database can update a row, delete a row, or backdate a timestamp. Nothing downstream detects it. The integrity of the record rests on the good behavior of exactly the people the record exists to check.
Proof of Change removes that dependence. Every change record is content hashed with SHA3-256 and committed to the record before it. The question stops being whether you trust your administrators and becomes whether the chain recomputes.
What the estate looked like before anything touched it belongs to the previous layer, Proof of State. This layer owns the transition: who moved it, on what authority, and whether the story can be rewritten.
45156354fe535c45f9790e29e09361a74e0fcb60916947b97f618fa0ede7c39dprev:60d850c9f7c3What we actually record
One record per change, whether the actor was a person in the portal or an agent inside its envelope. The field names below are the real ones. Read the schema before you believe the paragraph.
- actor
- The identity that made the change: a human principal or a named agent identity with its own credentials. An agent is an actor in the record, not a service account borrowed for the night.
- authority
- The policy decision id and approval reference that permitted the change. In GATED mode that is the approving human. In AUTONOMOUS mode it is the envelope and the gate results that stood in for one.
- state.before
- SHA3-256 content hash of the state captured immediately before the change. The capture is the input to the rollback contract, not a description of it.
- state.after
- SHA3-256 content hash of the state after apply. The verify step recomputes it, and a mismatch triggers automatic rollback.
- delta.hash
- Hash of the computed difference between before and after, so the change itself is committed, not just its endpoints.
- rollback.id
- The identifier that reverses this exact change through a single API call. Every recorded change ships with its counterfactual: the state as if the change had not happened, executable on demand.
- gates
- Which policy gates evaluated before execution and how each resolved: blast radius bounded, state pinned, policy passed. 3/3 required to proceed.
- captured.at
- When the record was written. Every claim in the evidence base reads as of a timestamp, and the base regenerates to any historical one.
- chain.prev
- SHA3-256 digest of the previous record. This field is what makes the log append-only in effect rather than append-only by policy.
Exhibit C-1 · every control in one of five states, and the changes the platform is permitted to make flagged per control. Illustrative demo data; the interface is real.
# agent action at 02:14 UTC, AUTONOMOUS inside envelope record chg-2026-08-31-004217 captured.at 2026-08-31T02:14:07Z actor agent:pcx/drift-remediation authority policy.decision=pd-9f21c approval.ref=envelope/drift-hygiene-v3 mode AUTONOMOUS confidence=0.97 (class threshold 0.94) action nsg.rule.remove_inbound_any gates blast.radius=pass state.pinned=pass policy=pass (3/3 required, 3/3 passed) state.before sha3:41c2e97a10bd state.after sha3:b8e07d2261f4 delta.hash sha3:77aa90c3d51e rollback.id rb-004217 (reversible via a single API call) chain.prev sha3:d34db6a5f210
39e8137d7c793351e48f6cb9b703ba1cc16a561bbb68b77d629b0964435ee6fbprev:45156354fe53How the record is verified
The change log is append-only, hash-chained JSONL. Each record carries the SHA3-256 digest of the record before it, so every line commits to the entire history above it. Edit one record, anywhere, at any time, and every digest after it stops recomputing. Verification is mechanical: recompute the chain from the first record forward, and the run returns one of two answers, intact, or the sequence number of the first record that breaks.
That answer is an attestation a second party can reproduce. An assessor does not have to trust our tooling or your administrators: the digests recompute from the records themselves. Retention is seven years, and the evidence base regenerates to any historical timestamp, so as of is a parameter you pass, not a caveat you add.
Changes made around the system, in the portal, through a direct API call, from a pipeline that never met a gate, surface at the next state capture as drift records with no authority attached. A change with no authority is not a blind spot. It is a finding, and it is recorded as one. The same discipline applies when collection fails: if a collector is down or a scope is unobserved, the log contains a declared gap entry with the interval and the reason, never silently fewer rows.
All of it runs inside your tenant. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence, so the chain never depends on records that left your boundary. Where the log lives and how collectors reach it is covered in the architecture.
$ pcx verify change records 84112 recomputed 84112 head sha3:9c4af0b21e77 result INTACT $ pcx verify change (same log after one row edited in place) result BROKEN at seq 61204 note every digest from 61205 onward fails to recompute
8ebcf1dc320ded7b048728cbe204fa1dd3c3ef5d4c9beb4a5f11a732b8f759d8prev:39e8137d7c79What this layer does not do
aa8f5808d30bc79f0fb96e80923fc035788c0b8204be9d1405f0de40e8e64d4dprev:8ebcf1dc320dWhere it maps
Change evidence files under configuration management and protection of audit information. The mapping is deliberately quiet: the record is the product, and the rows below are where assessors expect to find it. SSP, POA&M, and SAR narratives generate from the same implementation record, exported as OSCAL 1.1.2.
- NIST 800-53
- CM-3 configuration change control, AU-9 protection of audit information, AU-10 non-repudiation of who did what.
- NIST 800-171
- 3.3 audit and accountability, 3.4 configuration management, within the same evidence base that covers all 110 requirements.
- CMMC Level 2
- Change and audit records handed to your assessor as generated evidence, not screenshots assembled the week before.
- MITRE ATT&CK
- Defense evasion: indicator removal and audit log tampering become detectable events, because the chain breaks exactly where the edit happened.
Make a changed record reveal where trust broke.
Request verification