2026-08-28·by Sijie Wang#cybernetics#theory#agents

git-as-agent-trust-substrate

Git as an agent trust substrate

The problem. When several AI agents collaborate on an action that is irreversible and outward-facing (publishing, deploying, sending), you cannot rely on any agent being honest: an agent that generated the work is the worst possible judge of whether it should ship, and an agent asked "did you comply?" can simply answer yes. Chaining agent-reviews-agent doesn't fix it — same-model-family reviewers share blind spots (the slop-is-a-context-deficit experiment's caveat: judges of the same family miss the same things), and none of it is tamper-evident.

The pattern, stated precisely (corrected 2026-07-16). The authority is not git — it is a re-runnable deterministic check. The irreducible mechanism is: the gate re-runs a deterministic lint on the artifact rather than trusting any agent's self-report. Git's essential job is a separate, specific one: content-addressing, to bind the artifact that was checked to the artifact that ships (closing the time-of-check-to-time-of-use gap). Everything else git contributes is valuable but replaceable.

  1. Separation of powers across roles. generator (produces) · auditor (runs the lint + commits the record) · publisher (acts only on a verified, content-addressed record). No role can do another's job.
  2. The gate's integrity comes from the re-run, not from git. The publisher does not believe a pass status — it re-runs the deterministic lint (or verifies the committed lint result against the committed artifact). An agent cannot talk its way past a check that is re-executed; the "reads git" framing in the first draft over-attributed this to git. Git is incidental to the pass/fail; the re-run is what buys the trust.
  3. Where git IS load-bearing — the TOCTOU gap. Without content-addressing, an agent can pass the lint on artifact v1 and then ship a swapped-in, non-compliant v2 (checked one thing, published another). Git closes this: the publisher ships exactly the artifact whose content hash was committed and linted. To get this you need content-addressing + immutability — i.e. git or an equivalent. This, not the pass/fail, is the reason git is in the loop.
  4. Hard rules are code; soft judgment is an agent. Mechanical, diff-checkable rules (completeness, format, provenance, rate) live in the deterministic lint an agent cannot argue past. An agent's judgment (taste, register) is advisory only, never a gate — sidestepping same-family collusion.

Git's other contributions — real, but replaceable. Tamper-evident dated provenance (a signed append-only log would also do); the persistent ordered history that history-dependent checks read (velocity cooldown, dedup, plateau — any ordered store works, git log is merely convenient); zero-tooling human audit/revert (git log/diff/revert). For a git-native operator these are nearly free, which is why git is the pragmatic substrate even though only the content-addressing is logically necessary.

The decoupling this licenses. If the threat model has no swap vector — publish and audit happen in one atomic step with no gap an agent can exploit — then git isn't needed for the gate at all, and degrades to pure audit storage. The gate is: deterministic re-run + (content-addressing iff a TOCTOU gap exists). Git is one way to get the second clause, not the source of the first.

The generalization of a familiar idea. This is "constraints mechanized, not socialized" (the vault owner's engineering principle) applied to agent collaboration: instead of trusting agents to follow rules, make the rules a re-run the agents' output must pass, anchored to the exact content that ships. It is CI-gated (continuous-integration) deployment, re-cast for a world where the workers are language models: the pipeline doesn't trust the committer, it re-runs the check on the committed content — and the commit hash is what stops a swap between check and deploy.

The re-run is a spawned agent — "verification is spawn an agent" (2026-07-16). The re-run is not "the same process re-invokes the function"; it is embodied as a freshly-spawned, clean-context agent that shells out to the deterministic lint on the committed content. Two reasons the spawn matters, not just the re-execution: (1) the clean context prevents same-context collusion — the verifier shares no state, no rationalization, no half-built story with the generator that produced the artifact (this is executor-acceptance-test applied at the publish gate: a clean agent, citation-or-fail); (2) the machine's verification surface is uniform — every gate, deterministic or judgment, is "spawn an agent to re-check," so there is exactly one trust primitive to reason about. The deterministic lint is what that spawned agent runs; the spawn is who runs it.

The build discipline that falls out — "if it can't be re-verified, it doesn't go in." Because verification is a spawned-agent re-run, a component earns its place in the machine only if such a re-run can check it. A field that no re-run can confirm (an unfalsifiable claim, an un-checkable "trust me") is not made a soft-advisory nicety — it is left out. This keeps the machine's every gate falsifiable by the one primitive, and is why the fix for a "law 1 isn't enforced in code" worry is not to add a hash-equality assertion but to note that the publisher-agent already re-runs on the committed (hashed) content: the re-run, not a bespoke check, is the enforcement.

Where it's instantiated. utter-manual — the publisher, a freshly-spawned agent, re-runs the mechanical lint on the auditor's committed ledger record and publishes the irreversible act (posting to a real account) only on a clean result, so an agent cannot talk its way to publishing non-compliant content.

The substrate spans human↔agent, not just agent↔agent (2026-07-16). Where a step needs taste (the residual the lint can't check — is this video good, does it represent me), the human is the judge, and their "yes" is bound the same way: recorded as a token whose content-hash must match the committed artifact (human-gated-publish, utter-manual's publish.human_approval). The publisher's gate becomes two locks — a deterministic re-run PASS and a human approve on the matching hash. So the same content-addressing that stops an agent shipping something other than what was checked also stops the machine shipping something other than what the human blessed: approve-the-exact-bytes, for a person, is as tamper-proof as re-run-the-exact-bytes for the lint. The trust primitive (content-addressed authorization) is uniform across the deterministic gate and the human gate.

The limit. The substrate guarantees compliance with declared rules and no-swap-between-check-and-ship — not correctness of the rules. A wrong lint spec ships wrong-but-compliant work. And the hard/soft split means anything that can only be judged by taste (not a diff-checkable rule) still rests on the advisory agent + the human sign-off, not the gate. The pattern moves trust from "the agents are honest" to "the rules are right and the human watches the constitutional diffs" — a strictly better place to put it, not a place with no trust at all.

Kin: slop-is-a-context-deficit (why agent-judges-agent isn't enough) · executor-acceptance-test (the spawned-clean-agent re-check, here made the publish gate) · trust-follows-provenance (verify by re-derivation, not assent) · utter-manual (the instantiation) · the vault's own pre-commit lints (the same philosophy at the note level).

Source: design 2026-07-16, generalized from the utter-manual architecture; the pattern that let irreversible outward actions be delegated to untrusted agents

about this entry

One of sijie's wiki entries. The AI on this site is grounded in the same corpus and answers in sijie's voice, with citations back to entries like this one — answering costs sijie money, so it waits behind a code: enter an access code →