Change-management evidence for code written by agents

Agent Change Control

A record of what wrote each change and who approved it
Sealed, timestamped, verifiable offline by your auditor, without us

From our own published pack · one committer · 58 rows

The same pack, verified offline

What we measured501 public repositories at 19 organizations, 15 regulated fintechs and 4 AI coding-tool vendors, none of them ours · one year

A third of disclosed agent work merges with nobody independent approving it.

Independent approval here means an approving review from a human account other than the pull request's author. The pack applies a stricter test: other than every account that authored a commit in it.

disclosed an agent, no independent approval
disclosed an agent, independently approved
no signal, no independent approval
no signal, independently approved
one square is ten merged pull requests

Public GitHub, measured from outside, with the method published. A disclosure rate, not a share of code written, and not a claim about any firm's internal agent use. Code and data: github.com/theruviparambil/agent-attribution-method, MIT. Rerun it yourself.

Why now, and not next year

Your auditor tests this every year, on a date that does not move.

Change management is an IT general control. For systems in scope for financial reporting it is tested every year, and under PCAOB AS 1105.10 any change population your company hands the auditor must be tested for accuracy and completeness before they can rely on it.
That control assumed a person wrote the change and a different person reviewed it.
Agents made that ambiguous, and nobody told the auditor. The pack is the merged-pull-request part of that population, with the attribution signal and the approval on every row, in a form your auditor can test without asking you.

“the preparer and reviewer are not independent of the activity to which they are attesting”

First Interstate BancSystem, a US bank, Form 10-K for fiscal 2023, filed 29 February 2024: one of the combined control deficiencies that added up to a disclosed material weakness, a change-management segregation-of-duties deficiency over two systems. Its auditor issued an adverse opinion on internal control over financial reporting. Management reported it remediated as of 30 June 2024. The filing mentions no AI. The control was already fragile before agents arrived, and agents now write the changes.

The evidence packA real pack, published with its key and its timestamp

The published pack is our own repository: one committer, so every row reads no.

One committer can never show an independent approval. The point is that you can verify the pack yourself, offline, and nothing contacts us. Published in full at github.com/theruviparambil/falden-verify.

Evidence pack Agent change control

theruviparambil/veriva-monorepo · Falden's own codebase · pack v2

Scope: 1 organization, 1 repository
Window: 90 days
Pull requests: 58
Commits: 102
Sampling: none, full population

40of 58 merged pull requests

carried an AI attribution signal and had no approving review from a human account other than every account that authored it.

13of the 40 changed 500 lines or more

28of 102 commits carried no attribution signal, reported as an evidence gap, never as human-written

0of 58 had any approving review, independent or not

Change register, first four of 58 rows, as published
Pull request	Attribution	Approved by	Lines	Independent approval
#441	Claude Opus 4.8, Co-authored-by trailer	none	418	no
#439	Claude Opus 4.8, Co-authored-by trailer	none	16	no
#438	Claude Opus 4.8, Co-authored-by trailer	none	4	no
#433	Claude Opus 4.8, Co-authored-by trailer	none	4	no

Pack SHA-256: 725335d11bece060f2a447a650ffe378e73c71b8b800819ce9aacd928f7ac55f · 360,503 bytes
Chain root: 816c3a4122cef214366550c064dd72dd19be167649a6fbbbc9ddd4d9d9dc2ab2
Key fingerprint, SHA-256 of the DER public key: 72e91be823e5e1d669a3510ce1d7cf6648325d3d8cea83f7362d42ead37ff1be
Sealed: 2026-09-01T08:53:26Z
Timestamp: RFC 3161 · freetsa.org · 2026-09-01T08:53:27Z · serial 0x076C9486

People appear as stable pseudonyms computed under a salt that stays inside your organization. Machine accounts stay legible, because which agent wrote a change is the finding. The signature is over the SHA-256 of the whole file, so one changed byte fails it.

Verify it yourself, right now, without us

git clone https://github.com/theruviparambil/falden-verify && cd falden-verify/example
digest=$(openssl dgst -sha256 -r pack.json | cut -d' ' -f1)
printf 'falden-pack-ed25519-v1\n%s\n' "$digest" > message.bin
openssl pkeyutl -verify -pubin -inkey falden.pub \
  -rawin -in message.bin -sigfile pack.json.sig

What you will see: Signature Verified Successfully

Change one number in pack.json and run it again: Signature Verification Failure

OpenSSL 3. macOS ships LibreSSL, which lacks -rawin: brew install openssl, or run the verifier in the repository.

An Ed25519 check against a key we publish, in stock openssl. A verified seal proves the file in front of you was produced by the holder of Falden's key and has not been altered since.

It does not prove the measurements are correct or that any control is deficient. The RFC 3161 token is checkable with openssl ts against the authority's chain, shipped in the same directory or fetched from freetsa.org.

The assessmentRead-only · one organization · ninety days · every merged pull request

One organization, the last ninety days, every merged pull request.

A read-only GitHub App (GitHub only, today), one organization, and a sealed pack your auditor verifies offline. Six to eight weeks end to end, most of it your vendor-risk review. Your engineering time: two hours of one manager. Fixed scope and fixed fee, agreed before work starts.

Two read permissions, and what they do not prove

Requested

+Metadata (read)mandatory on every GitHub App, to list repositories and their merge settings
+Pull requests (read)reviews, approvals, commits and line counts

Not requested

×Contents
×Repository administration
×Organization audit log

A read-only GitHub App on one organization. GitHub shows you the list before you approve it, and it proves less than it looks: pull requests (read) is on its own sufficient to fetch a diff.

What stops us reading source is the collector, not the permission, and the register below is our own account of it. The contents endpoint is refused before a request is issued, the allowlist is deny-by-default, and every outbound request is listed in the pack, under the seal. The published pack's register: 176 requests, one host, five path shapes, none of them a contents, files or blob endpoint. The token the collector holds expires in an hour.

What this permission set cannot see, seven items

Any change authored by a model deployed inside your perimeter that emits no trailer and commits under an undeclared identity.
File contents, diffs and patches. Contents was not requested and the collector refuses the files endpoint.
Branch protection configuration, and whether a required gate was configured. That is repository administration.
Administrative overrides, required-check skips and force pushes, as a complete log. Those live on the organization audit log. Bypass coverage is therefore partial.
Whether a review was substantive. An approval is recorded as an event; its depth is not observable from this permission set.
Any change that did not arrive through a pull request on an installed repository.
Whether the recorded commits remain reachable from the default branch after a squash or rebase merge. You tell us your merge setting per repository; we do not detect it.

A pack that silently omits looks identical to one that found nothing. Every item above is declared in the pack itself; the ones this permission set can observe are counted.

Standard scope: One GitHub organization, one legal entity, up to five hundred contributors active in the window. Collection from Falden infrastructure, or from a collector run inside your own perimeter, quoted as a line item.
What is measured: What wrote each change, where a trailer or bot identity makes that determinable. Who approved it. Whether that approver authored any part of it. How much changed. How long approval took.
What you receive: A sealed pack: machine-readable JSON, a hash chain over the commit object identifiers you can re-derive from your own clone, an RFC 3161 timestamp token, our public key, and the MIT-licensed verifier your internal audit team or your auditor runs offline. Every merged pull request the API returns for the window, with anything the record cannot establish listed in the pack's not-visible register.
What this is not: We supply the record. Your auditor tests it. We are not the attestor and we issue no opinion. Whether a measurement is a deficiency is a call for your control owners and your auditor, not for us.

Request an assessment

Enough for a first conversation. Nothing here commits you to anything, and I read these myself.

Alexander Theruviparambil, founder

Work email required Organization required What prompted this requiredIf any of this is confidential, take the last option. Anything else optionalThe question you would struggle to answer if your auditor asked tomorrow.

No newsletter, no sequence. One reply, and at most one follow-up. If any of this touches confidential supervisory information, leave it out and we will talk instead. Or write directly: alexander@falden.ai.

What happens next: I reply myself within two working days. Then a thirty-minute call, an NDA before it if you want one, then a signed scope.