The Ledger

The record, read as evidence.

Who did what, reviewed by whom, signed and anchored outside the repository.

Which agent, model, and version made each change. Which person reviewed it. Signed, chained, anchored outside the repository, and verified offline by whoever asks.

Our own record right now: Chained and anchored through 2026-10-25.

Talk to us Open our live Ledger

Sessions · 22 with identity

753

Changes · 0 reviewed, 753 commits

Days chained · 39 anchored

753

Unreviewed · shown, never hidden

On a board with one person, every change shows as unreviewed, and the record shows exactly what happened: no second person reviewed it. Review here means a named person other than the one who made or directed a change read it, so a team of one has nobody who can. On a team, the same record shows each reviewed change, a merged pull request, a release, or a single commit, with the person who reviewed or approved it, and lists every change no one reviewed, which is what an assessor checks.

The rule

DoW Instruction 8430.01, Accelerated Mission Software (DoWI 8430.01), took effect on September 8, 2026. Nobody has published how a software factory using coding agents will meet it.

The instruction says that "AI-generated code will be considered unverified input" and that Components "will implement a risk-based review that, at a minimum, requires human review and approval for AI-generated changes to security- or safety-critical functionality" (3.6.a(2)). All code generated by AI "will be subject to the same or similar rigorous code review and security testing processes as manually written code" (3.6.c(1)).

Software efforts "will maintain a record of models, versions, and significant datasets used to generate or test software," included "as part of the comprehensive software evidence package, analogous to the SBOM" (3.6.f). The build process will produce attestations that provide pedigree, "a cryptographically verifiable chain of custody and integrity for the software and its components" (3.5.c(1)), and approved AI services must "allow for auditing and monitoring of their use" (3.6.d(2)).

In February 2026 the Chief Digital and AI Office and the Army issued solicitations requiring attribution and traceability for AI generated code. FedRAMP's machine readable package rule applies to new packages from September 30, 2026, and its 20x indicators ask for tamper resistant change logs and identity for accounts that are not people.

The instruction asks for	What Attestia records	Insufficient when
AI generated code is unverified input, reviewed like manually written code (3.6.a(2), 3.6.c(1))	a review record per agent authored commit, by a named person who is not the director	review is self review or a summary approval; the caveat is shown
Human review and approval for AI generated changes to security or safety critical functionality (3.6.a(2))	protected paths in the policy file, review required there, exceptions recorded and signed	protected paths not declared
A record of models, versions, and significant datasets used to generate or test software (3.6.f)	model and model version per session, from the runtime	the runtime does not report; the field is null and shown
Included in the comprehensive software evidence package, analogous to the SBOM (3.6.f)	the export: PDF, JSON, and OSCAL	period not covered by the chain
Non public information not processed by generative AI services that are not approved (3.6.b(1))	the policy file's model allow list, the hook refuses banned models, the policy hash per session	policy absent
Approved AI services must allow auditing and monitoring of their use (3.6.d(2))	which model, which version, which session, directed by whom, per interval	the runtime does not report the model
Pedigree: a cryptographically verifiable chain of custody and integrity (3.5.c(1))	signed commits and the chain, anchored outside the repository	signing not enforced; no anchor

The record is evidence toward these requirements; the instruction names no tool and defines no evidence format yet (3.5.a(2)). Quotations are from the primary text, cited by paragraph. The assessor decides sufficiency.

What the Ledger is

A bookkeeper's word, and a promise with three parts.

A ledger is the permanent, append only book of every transaction: what, when, who, how much. Entries are never edited; a mistake gets a correcting entry. A log is something you write for yourself and can lose. A ledger is something another party can audit later and trust.

The Ledger is not a second product. It is the same record the Board reads, kept in your own git, with three things the Board does not need: identity per session, a human review record per agent authored commit, and tamper evidence.

Signed
Every entry is signed by the identity that made it.
Chained
Entries are chained, so removing or altering one is detectable.
Anchored
The chain is anchored outside the repository, so the audited party cannot rewrite its own history. Without this it is a log with extra steps, and an assessor will say so.

What it records

Two records the Board never needed: who ran each session, and who reviewed each commit.

Per session

When a coding session starts, the hook in the agent runtime writes who directed it (the person, matched from git and the team file) and what ran it: runtime, version, model, model version, the tools it was granted, and its permission mode. Every field comes from the runtime, never typed by a person. If the runtime cannot say, the field is null and the board shows "not reported".

From our own record: Aatir, 29 Sept 2026Live

{
  "startedAt": "2026-09-29T18:12:35.407Z",
  "endedAt": "2026-09-29T18:12:38.538Z",
  "agent": {
    "runtime": "claude-code",
    "runtimeVersion": "2.1.284",
    "model": null,
    "modelVersion": null,
    "tools": null,
    "permissions": null,
    "policyHash": null
  }
}

Per commit

Each commit is attached to the session that made it, so direction is known: a commit made in an agent session carries the session's id in a trailer, and a commit without one is matched to its session by time. The Ledger adds a review record: a signed statement that a named human reviewed the commit, distinct from authoring it, signed by the key the team's signer registry gives that person. It is captured where review already happens, an approved pull request, or written from the terminal with one command for teams that ship straight to main. The reviewer is never the session's director unless the team turns self review on, off by default and shown as a caveat when on.

The shape of a review record. Our own board shows every agent authored commit as Unreviewed until one is written, and says so rather than hiding it.Example

{
  "commit": "3f1c9a2e",
  "reviews": [
    {
      "reviewer": "maya",
      "reviewedAt": "2026-09-19T16:10:00.000Z",
      "source": "pull_request",
      "pullRequest": 42
    }
  ]
}

Every agent authored commit shows one of three states:Reviewed by a named personSelf reviewed, a caveatUnreviewed, never hidden

Tamper evidence

Three mechanisms, all on by default once the Ledger is enabled.

Signed commits

Every tracker commit is signed, with Sigstore by default so no key management is needed, or GPG where a team already has keys. The validator checks every tracker commit and fails the build on an unsigned one from the day signing was required.

The nightly chain

The close writes one entry per day holding the hash of every record file it wrote and the hash of the previous day's entry. One line per day, and the validator walks the whole chain.

External anchoring

The close publishes the day's chain hash to a transparency log outside the repository: Sigstore Rekor, OpenTimestamps as a second anchor, or your own endpoint. The receipt is stored beside the entry. The Ledger labels itself "not anchored" whenever it cannot prove otherwise, in every view and every export.

Coming next A self hosted anchor: a transparency log you run yourself, with receipts identical to the public ones, so an air gapped program anchors without the internet.

Our latest chain entry, 25 Oct 2026: 3 files, anchored with rekor and opentimestampsLive

{
  "day": "2026-10-25",
  "hash": "634738004dc2b7b6b5200538dd2564a48802365f2911c65f4600b1ea1255d8b4",
  "previous": {
    "day": "2026-10-24",
    "hash": "7cda0282bd487cbb1607d263c483e00ebc3309ee06d5eaf04550202af361737f"
  },
  "anchors": [
    {
      "kind": "rekor",
      "at": "2026-10-26T11:30:12.402Z"
    },
    {
      "kind": "opentimestamps",
      "at": "2026-10-26T11:30:13.191Z"
    }
  ]
}

Verify

One command replays the chain, checks every signature and every anchor, offline, and prints a verdict. An assessor runs it, not us.

$ npx @attestia-dev/cli verify --offlineverify 2026-09-18 to 2026-09-18, 1 day, offline, zone America/New_Yorkok   2026-09-18  chain ok, 1 file intact  |  signed 4/14, 10 unsigned (not required then)  |  anchored: rekor #2886802074 (receipt present, not re fetched offline); opentimestamps proof from a.pool.opentimestamps.org (172 bytes; the Bitcoin attestation is not checked here)verdict: VERIFIED: 1 days chained, signed as required, and anchored outside the repository

Our own transcript, committed with the record on the first anchored day.

The control map

We say evidence for, never compliant with.

Each line names the control and its rev 5 baseline, what the record provides, what our own record shows right now, and the ordinary case in which the evidence is insufficient.

Control (NIST SP 800-53 rev 5)	The Ledger provides	Our record, now	Insufficient when
AU-10 Non repudiationBaseline: High	signed commits bound to a person or an agent identity, reviewer identity bound separately	signing required; run attestia verify for the count per day	signing not enforced; agents share a credential
AU-9 Protection of audit informationBaseline: Low, Moderate, High	chained daily hashes anchored outside the repository	39 of 40 closed days chained, 39 anchored outside the repository	no external anchor; the anchor is run by the same people
AU-3 Content of audit recordsBaseline: Low, Moderate, High	actor, time, event, outcome, session, and reviewer per commit, with model and version when the runtime supplies them	22 of 28 sessions carry the runtime and model	fields not reported by the runtime
AU-2, AU-6, AU-12 Event logging, review, generationBaseline: Low, Moderate, High	a defined event set and a queryable record	239 entries across 40 closed days, every one queryable	the organisation never defines events or reviews the record
CM-3 Configuration change controlBaseline: Moderate, High	a review decision distinct from the change, per change set where it enters the protected branch (a merged pull request, a tagged release, or a commit shipped straight to main), inherited by every commit in it; approvals on the host recorded as their own tier	753 change sets: 0 reviewed by a named person, 0 approved on the host by another person, 0 self reviewed, 753 unreviewed (753 commits)	self review or self approval; no impact analysis; review not required where the policy names it
CM-5 Access restrictions for changeBaseline: Low, Moderate, High	the review rule recorded, and what the git host enforces on the default branch, read at each close with every gap between the two named	the review rule is recorded; branch protection is read from the repository host in a later item	one identity can author and merge; the host rules unreadable, or not enforced by the host
CM-5(1) Automated access enforcement and audit recordsBaseline: High	the hard blocks: a denied model or tool refused at the moment of action, a commit with no session identity refused, each refusal and every break glass logged and chained	no policy file on this board; nothing is refused	no policy file; break glass used routinely; the runtime does not report the model
SA-10 Developer configuration managementBaseline: Moderate, High	the signed record of authorised changes across the build	signing required; run attestia verify for the count per day	no CM plan; the repository itself unprotected
SA-11 Developer testingBaseline: Moderate, High	test results tied to each commit, read from the CI host at each close, per check and per step, never from the agent's own report	test results are read from the CI host at each close into tracker/ci; nothing self reported counts	tests are self reported; CI does not run on every commit
SR-4 ProvenanceBaseline: High	which runtime produced each change and at what time, with model and version when the runtime supplies them	22 of 28 sessions carry the runtime and model	fields null
IA-9 Service identification and authenticationBaseline: withdrawn in rev 5 baselines; cite under IA-3 and IA-8	a distinct identity per agent session	22 of 28 sessions carry the runtime and model	agents share a generic credential
AC-6 Least privilegeBaseline: Moderate, High	the permission mode for each session, recorded when the runtime supplies it	1 of 28 sessions record the permission mode	recorded but not enforced (see Policy); and no current agent runtime exposes the list of tools granted to a session, so the record names the mode and not the tools

Control map version 2026-09-25.1. The map is a file in the repository so it can be revised when NIST publishes the agent overlays, and the evidence export always ships the current version.

Where the same controls sit in other frameworks

The families above are referenced, not redefined, by the frameworks a federal or defence buyer will name. The mapping is by control family; the buyer's assessor decides sufficiency.

Row above	CMMC 2.0 (Level 2 practices, from NIST SP 800-171 rev 2)	FedRAMP (Moderate and High baselines)
AU-10	3.3.2 Ensure actions can be traced to individual users	AU-10 in the High baseline; not selected in Moderate
AU-9	3.3.8 Protect audit information and tools from unauthorized access, modification, deletion; 3.3.9 Limit management of audit logging to privileged users	AU-9, with AU-9(2) off system backup in High
AU-3	3.3.1 Create and retain audit records with the content needed to monitor and investigate	AU-3, AU-3(1) additional content
AU-2, AU-6, AU-12	3.3.1, 3.3.3 Review and update logged events, 3.3.5 Correlate audit review	AU-2, AU-6, AU-12
CM-3	3.4.3 Track, review, approve or disapprove, and log changes	CM-3, CM-3(2) test and validate in Moderate and High
CM-5	3.4.5 Define, document, approve, and enforce physical and logical access restrictions for change	CM-5, CM-5(1) automated access enforcement in High
CM-5(1)	3.4.5 as above; the automated enforcement and its audit records are what 29-federal-map.md section 3 calls the hard block tier	CM-5(1) in the High baseline
SA-10	not a Level 2 practice; relevant to Level 3 through 800-172	SA-10
SA-11	not a Level 2 practice	SA-11
SR-4	not a Level 2 practice; supply chain under 800-172	SR-4 in the High baseline
IA-9	3.5.1 Identify system users, processes acting on behalf of users, and devices	IA-9 was withdrawn into IA-3 and IA-8 in rev 5 baselines; cite the session identity under those
AC-6	3.1.5 Employ the principle of least privilege	AC-6 and its enhancements

What the map does not claim

No row means a control is satisfied. The third column names the ordinary case in which it is not.
Tests are evidence only when they come from CI, never from what an agent wrote in a commit message or a session.
A chain without an external anchor is labelled "not anchored" in every view and export; AU-9 is not met by it.
Policy (25-the-record.md section 8) records the rules a session ran under; it is not a control plane and the map does not present it as one.

Enforcement

An optional policy file, three tiers, and a rule about what Attestia is not.

Advisory, everything by default

The pull request check annotates each agent authored commit with its identity and review state and lists policy warnings. It never fails. The Ledger shows the same.

Recorded exception, protected paths

A commit to a protected path without a review record fails the check unless an exception covers it, signed by an approver who is not the requester, with an expiry. The check passes with the exception shown.

Hard block, three cases

A session refuses to start under a banned model or tool. A commit with no session identity fails the build when the Ledger is on. An agent's own approval never counts toward a required review. Each has a break glass that writes a signed, logged, chained entry and lets one action through. Break glass never disables the rule.

Coming next The break glass command.

The policy hash is written into every session, so a later reader knows which rules applied. Policy is not a control plane; it is the rules the record was kept under. Attestia is never a change advisory board.

The exception record

When a rule is waived, the waiver is part of the record, and an assessor reads it as the control working.

An exception waives the review requirement on a protected path, and nothing else. It takes one of two forms. A window names a path, the reason, who asked, and who approved, and covers commits to that path from the moment it is issued until it expires; the nightly close records each one against it. The one commit form names a commit that merged without a review and covers that commit alone. Either way, it is signed by the approver.

Coming next The window form, and a signature on every exception, in the release after 0.4.0.

A person grants an exception, never an agent: the command refuses inside an agent session, and with a signer registry the exception must be signed by the key registered to its approver. The approver is never the requester, and must be on the policy file's approver list when it names one. A window lasts thirty days at most. Only a commit recorded against it is covered: one with no review, dated inside the window, that reaches the close within 36 hours of the window ending. A commit after the window closes needs a review or a new exception, and a commit already recorded stays covered. Every exception is sealed into the chain. Exceptions have their own row on the Ledger, their own section in the export, and count under CM-3 and CM-5 as evidence of the control working.

The software evidence package

Named for what DoWI 8430.01 asks for (3.6.f). One command writes it for a period; names become roles and hours stay out unless the exporter asks for them.

$ npx @attestia-dev/cli export --from 2026-09-01 --to 2026-09-30attestia-evidence-2026-09-01-2026-09-30/

evidence.pdf

A cover sheet, then sessions with identity, commits with review state, exceptions, refusals, break glass, the chain and receipts, for a reader.

evidence.json

The same, machine readable, with the verdict.

verify.txt

The verification transcript, one line per day.

control-map.md

The map at the version the export was made, with the insufficient when column.

oscal/component-definition.json

OSCAL 1.1.2: the record as a component with its implemented controls.

oscal/assessment-results.json

OSCAL 1.1.2: one observation per control with evidence references and their hashes, validated against the NIST schema.

The package never includes note screenshots, Ask threads, emails, or prompt text.

Where it fits

Runtime observability watches agents in production. Nobody watches the agents that write the software.

The Ledger records what agents did while the software was being built, inside your boundary, and it will export sessions and commits as OpenTelemetry spans so both sit in one dashboard. In the category a reader searches for, this is the build time record for AgentOps and agentic engineering; on this site it is the Ledger.

Coming next The OpenTelemetry export.

Deploying it

The record lives in your git either way. The question is only what reads it and what leaves.

Hosted

The hosted board reads your repository through a GitHub App your organization installs once, with three permissions: contents read and write, issues read and write, metadata read. Accounts and an audit log live in our database; the record never does.

What leaves the boundary

One hash per day, sent to a public transparency log, and the receipt that comes back. Nothing else. An enterprise can point that anchor at its own log instead.

Self hosted and air gapped Coming next

The same app pointed at your own git host, with your own anchor, as a template.

The full boundary in plain words is on the security page.

Talk to us

Tell us the project and the assessment it faces. A person replies, with an evidence package for a period of your own record if you want to see one first.

Or write to hello@attestia.dev. Pricing for the Ledger and Enterprise tiers is on the home page.