--- title: "My Agents Could Edit Their Own Checks" description: "Inspectable AI governance links a specific claim to enforcement, observed evidence, and an accountable owner. Build a versioned evidence pack that names covered routes, prohibited and legitimate cases, missing observations, and changes requiring rechecking. Preserve exceptions and uncertainty. The proposed publishing example shows how to review that chain without claiming a completed audit." author: "Justin Bartak" published: 2026-11-04 modified: 2026-11-04 canonical: https://www.orbytlabs.ai/blog/ai-governance-you-can-inspect --- # My Agents Could Edit Their Own Checks My agents could edit the checks that judged their work. An outside review found the problem. The agents and the checks shared a writable repository. I described the finding in [my audit account](https://www.orbytlabs.ai/blog/two-ai-audit-loop-codex-claude): I had built a check to read live production state. Repository checks inherit the repository's blind spots. “I still did not apply it to the machinery itself.” That is a concrete governance failure. A rule can exist. Tests can pass. The actor can still change the instrument that declares the result. I want another person to be able to inspect the rule, the action, the observation, and who controls each one. **A governance claim is only as strong as the weakest unverified link between the rule and the real action.** I start with one testable claim. A research agent cannot publish a report unless a person approves that exact revision. This is a proposed example, not a claim about current Orbyt publishing controls. ## What belongs in the evidence pack? An evidence pack is a small, versioned collection of claims and the records needed to assess them. It must show what I checked, what I did not check, and who can alter the checking machinery. I would use one pack for one consequential action. Publishing has its own destination. So do permission changes and messages. Each can fail in different ways. A general statement that an agent follows policy cannot establish any of those effects. | Field | What I would record | | --- | --- | | Claim and scope | Actor, action, environment, report revision, and covered routes | | Consequence | What would be wrong if the claim failed | | Control and authority | Enforcement point and who can change its rule or code | | Observer and authority | Reader, data source, and who can change the reader or its evidence | | Cases | Prohibited action, legitimate action, and missing observation | | Results | Expected outcome beside actual output and destination state | | Owner and validity | Person responsible, versions, exceptions, and recheck triggers | The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a broader voluntary approach to managing AI risks. My table is a proposed way to examine one operational claim. Completing it would not establish conformity with every framework requirement. I keep the scope narrow. A test of the ordinary interface in staging says nothing by itself about a direct API call, a scheduled task, or production. Each route needs its own result or an explicit blank. ## How would I inspect a publishing restriction? I would list each route that can publish: the ordinary interface, direct API, scheduled job, and administrative access. I would locate each route's enforcement check. Then I would identify its editors. A disabled button would not settle whether its endpoint remains callable. I would test an unapproved report, a report changed after approval, and the unchanged approved revision in an isolated environment. I would read the publication destination after each attempt. [My permissions account](https://www.orbytlabs.ai/blog/ai-agent-permissions-threat-model) explains why I care about the routes an actor can actually reach, including combined permissions. The legitimate case matters too: a control that blocks everything has not shown that approved work can proceed. The following is a synthetic example. Every report revision, role, route label, and timestamp in this pack is invented. I have not run it. No actual result was observed. | Pack field | Illustrative value | | --- | --- | | Claim | A research agent cannot publish report R17 without human approval of R17. | | Scope | Staging, editor interface through publishing service. Direct API, scheduler, and administrator routes remain unexamined. | | Versioned inputs | Draft policy P1, service revision S1, report R17 at 2026-10-01 10:00 UTC, illustrative approval of R17 at 10:05 UTC. All are invented. | | Proposed control | Service compares the acting principal, approved report revision, and requested revision before publishing. The operator role may approve; the agent role may not edit approval or policy. | | Prohibited cases | R17 without approval and R18 after approval of R17 should both be refused and leave the destination unchanged. | | Legitimate case | The same authorized actor submitting approved, unchanged R17 should publish R17 once. | | Missing observation | If the destination read fails, the verdict should be not observed, even if the service returns success or refusal. | | Observer and evidence | A separate reviewer would use a read-only credential to query the publication store and fetch the public report. The reviewer would retain the query, response, service output, and their timestamps outside the agent workspace. | | Observer authority | I would check that the agent cannot edit the query, reviewer credential, approval record, or retained evidence. Access control for those boundaries has not been checked here. A database administrator could still alter the store; the read is independent of the service response, not an infallible account of history. | | Owner and recheck | A human publishing owner would investigate a mismatch. Any change to permissions, routes, service check, reader, or evidence store would require a new review of affected claims. | | Actual results | Unapproved case: not observed. Changed revision: not observed. Authorized case: not observed. Destination state: not observed. Observer access: not observed. | That is a filled test design. It is not evidence that the control works. One route is covered. The others are still blank. Before I called the destination read independent, I would verify the agent's effective permissions against both the reader and its data source. A read made by another process is not independent if the agent can rewrite the query or the retained response. **A refusal followed by an unexpected publication is a failed control with an accurate-looking error message.** I would compare the service response with the destination state. If that read failed, I would stop short of a pass. The result would be “not observed.” This article reports no publishing drill or present production enforcement result. ## Can a log establish that an action happened? A log establishes what its writer recorded. Did the destination change? Did an independent reader check it? The log alone cannot establish either. Orbyt's experimental version 1 [Command Record specification](https://www.orbytlabs.ai/orbyt-collective/command-record) separates the request, execution evidence, and an independently established effect. Its Schema and fixtures section lists the observed.VALID.json fixture and explicitly says the fixtures test record validation, not independent reads. That limit is useful. A valid record can establish that fields and transitions meet the specification. I would still ask for the separate read before claiming the action happened. I would also ask whether the actor could change the reader, its credential, or the record holding its result. The [failure corpus](https://www.orbytlabs.ai/failure-corpus.json) records a different missing link in entry 41, dated August 10, 2026: an alarm inside a job cannot detect that no runner started the job. The job can contain correct monitoring code and never execute it. For a claim that missed work reaches an owner, I would inspect an observation outside the job, the delivery path, and the recipient. I would test the missing start and keep an unexecuted delivery exercise marked unobserved. [The governance paper](https://www.orbytlabs.ai/research/agent-leadership-governance) discusses why the machinery watching agents needs an evidence boundary of its own. ## When does evidence stop supporting the claim? Historical evidence stays historical. It does not become false when software changes. The inference from that evidence to the current system can fail. I would record the dependencies: policy, permissions, relevant model configuration, tool version, execution path, and observation method. When one changed, I would identify the claims that need another check. A new endpoint can bypass the publishing service. The old interface test can stay green. I would not rerun a publishing permission test for a typography edit unless it touched the route or observation. I would rerun it when an endpoint, permission, approval rule, or reader changed. I would preserve the earlier evidence with its date and state why it no longer covers the new path. An exception needs its own record. I name who accepted it, its scope, any compensating measure, and the condition that ends it. Risk acceptance does not turn a contradicted claim into a supported one. My [self-improvement account](https://www.orbytlabs.ai/blog/recursive-self-improvement-ceiling) describes repairs made in a shared implementation while copied workflows bypassed it. That is why I would name every examined route in the pack instead of treating a repaired module as proof of complete coverage. ## Does this create another pile of paperwork? It can. A hand-maintained pack can become a polished duplicate of records that drift elsewhere. The reviewer would then inspect the polish while the underlying state changed. I would keep one home for each fact. The pack would point to the policy, approval, test output, destination read, and owner instead of copying their contents into another document. I would preserve the versions used in the review and regenerate a summary only where the underlying records support it. I would not publish private inputs merely to look transparent. A public account can name the method and its limits. An authorized reviewer can inspect the underlying records through appropriate access. I want a reader to see which routes I checked and which remain unobserved, without claiming demand or an advantage I have not measured. ## What to do Next I would start with one claim about an agent action that matters. I would fill the pack. A separate reviewer would trace the route from rule to destination. I would give that reviewer authority to mark any link not observed. I would repair the first missing link before making the claim larger. The proposed publishing pack has no execution result. Its blank results are part of the answer. [Verification Is the New Literacy](https://www.orbytlabs.ai/blog/verification-is-the-new-literacy) explains why I keep the observation separate from the story I want it to support. Related reading: - [Governing an Agent Leadership Team](https://www.orbytlabs.ai/blog/governing-an-agent-leadership-team) documents verification gaps in the agent organization. - [391 Yeses and Not One No.](https://www.orbytlabs.ai/blog/ai-agent-permissions-threat-model) examines the combined reach of agent permissions. - [Verification Is the New Literacy](https://www.orbytlabs.ai/blog/verification-is-the-new-literacy) asks what an observation actually establishes. - [Trust Is the Product](https://www.orbytlabs.ai/blog/trust-is-the-product) connects evidence and human judgment in product decisions. **I can only call a control governed when I can show what it stopped, what it allowed, who observed the result, and who could change the observer.** This is the markdown version of https://www.orbytlabs.ai/blog/ai-governance-you-can-inspect. The page there is the canonical copy.