> ## Content Index
> Fetch the complete content index at: https://www.groktop.us/llms.txt
> Use this file to discover other available public pages before exploring further.

# Policy as Code Isn't Enough: Prove the Control Ran
- URL: https://www.groktop.us/governance-evidence/
- Published: 2026-09-24T12:00:42.000Z
- Updated: 2026-09-24T12:00:42.000Z
- Description: A policy file describes intent, not what happened in a live run. Follow Bernstein’s evidence paths to see what reaches the live route, what gets recorded, and what still requires human judgment.
- Author: Magnus Hedemark
- Tags: Enterprise AI, AI Strategy, agentic AI

What stopped the agent, and how do you know?

If you run autonomous agents anywhere near production systems that matter, someone will ask you that question sooner or later. Maybe it’s an auditor with a clipboard. Maybe it’s your CISO during a tense post-incident review. Or maybe it’s just you at 2 a.m., staring at a broken pipeline after hours and trying to reconstruct what that model actually did.

A green dashboard, a policy file in your compliance repository, and a passing staging test won’t answer it. None of that shows what happened on the live route. Did the guardrail execute before the agent acted, or did the model route around the check? Did the system record the decision, or only the outcome after the damage was done? If someone altered the log afterward, would you even notice?

[Bernstein](https://github.com/sipyourdrink-ltd/bernstein?ref=groktop.us) is an open-source project that makes the question concrete: was the control wired into the live path, recorded as it ran, and independently verifiable afterward? Its [execution journals](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/journal.py?ref=groktop.us), [audit chains](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/security/audit-log.md?ref=groktop.us), [receipts](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L308-L332), and [artifact lineage](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/concepts/artifact-lineage.md?ref=groktop.us) give you evidence to inspect. They won’t answer the question for you.

To test that claim, you have to follow a real run: did the control execute, did it leave a tamper-evident record, and can someone outside the system verify that trail without trusting the machine that wrote it? If that trail goes cold, you haven’t shown that the control ran. The project makes visible where software control ends and human responsibility begins.

## First, separate four different claims

When a vendor or internal team tells you they have “governance controls,” ask what they can actually prove. In practice, governance claims collapse into four distinct evidence states: Declared, Wired, Observed, and Verified.

![Four engraved symbols represent a policy seal, a live route, an observation journal, and an independent verification seal connected left to right.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/01-four-states.png)

Declared policy is only the beginning. The live route, run record, and independent check show whether a control held.

Start with **Declared** policy. That’s where most teams stop. The rule sits in a policy file or configuration repository, recording what someone intended to happen. It tells you nothing about whether the code actually ran.

Moving from intent to execution requires that the control is **Wired** into the live path. The execution path for an action has to physically pass through the check before the agent can touch an external system. If any tool adapter, script, or fallback route skips the check, the control isn’t wired for that route. It’s just decorative.

Even when a route is wired, you have to prove it was **Observed**. The runtime must generate a durable record: the prompt, the model checkpoint, each tool call, the inputs, and the outputs. If the agent executed in memory and left no durable trace, you cannot inspect it tomorrow.

Finally, there is **Verified** evidence. An independent person or process can examine the cryptographic proofs after the fact and detect whether anyone tampered with the record.

That distinction cuts through a lot of marketing noise. A policy can look immaculate in Git without ever touching a running agent, and a database log can remain pristine while completely missing the side effect that took down production.

[Quality assurance (QA) for agentic systems](https://www.groktop.us/agentic-qa-control/) has to test the control architecture alongside ordinary compilation. When an agent goes off the rails, your test suite should show what catches it and what evidence survives.

## What should a useful run leave behind?

When an agent does something unexpected, start with the outcome and trace the available record backward toward the decision that led there. If the trail stops short, that gap matters too.

![A landscape process diagram has three columns and a final verification box. BEFORE contains “Task,” “Policy,” and “Model + tools.” DURING contains “Trigger,” “Decisions,” and “Tool inputs + outputs.” AFTER contains “Artifacts,” “Journal,” and “Receipt.” A dotted arrow leads from Receipt to “Independent verifier.” The sequence shows the evidence trail from task setup, through recorded execution, to independent review.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/bernstein-run-evidence.png)

A useful run record starts before execution, captures what happens, and ends with evidence another person can verify.

Before an agent executes a single step, you need to pin down its intended task, the active policy version, its runtime configuration, and the tools it is permitted to use. As it runs, you want to capture who triggered it, its intermediate decisions, every tool input and output, and cryptographic hashes for any artifact it generates.

Bernstein’s [event journal](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/deterministic-replay.md?plain=1&ref=groktop.us#L23-L42) records events emitted by paths that use it, not a universal transcript. The replay guide limits model replay to the internal `call_llm` path; subprocesses launched by a command-line interface (CLI) agent bypass it.

The default [internal\_llm\_provider: none configuration](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/deterministic-replay.md?plain=1&ref=groktop.us#L25-L42) leaves that internal path inactive, so a CLI agent recording run writes no `llm_calls.jsonl`. Strict replay of a run without a recording raises [ReplayRecordingMissingError](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/deterministic-replay.md?plain=1&ref=groktop.us#L35-L42) before any agent is spawned. To record internal model calls, configure a provider and set [BERNSTEIN\_DETERMINISTIC\_SEED](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/deterministic-replay.md?plain=1&ref=groktop.us#L40-L42).

[Artifact lineage](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/concepts/artifact-lineage.md?ref=groktop.us) links outputs to their recorded inputs. The [audit chain](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/security/audit-log.md?ref=groktop.us) uses hash-based message authentication codes (HMACs) to help detect changes to recorded events; it can’t catch actions that bypass logging.

When Bernstein writes a signed [run receipt](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L308-L332), it binds the journal and lineage fields. [Offline verification](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L698-L724) lets another verifier check the signed receipt.

If you are designing this for your own infrastructure, test it against the practical questions an auditor or on-call engineer will ask:

- Can you prove which policy digest authorized the run and that the system checked it before execution?
- Do you know exactly which human or service account initiated the run?
- Which model version and runtime configuration did the run use?
- Does your log record every tool invocation, or only the model’s final response?
- Can you trace generated code or documents back to the source inputs that shaped them?
- Would a third party be able to verify the record without trusting the server that wrote it?
- Does the trace connect to your incident alerts and monitoring?

Keep your trust boundaries clean. If the audit log lives on the agent’s host and shares its write credentials, that host can rewrite the record when things go sideways. Store verification keys and logs somewhere the agent host cannot reach. Before you begin collecting prompts and tool payloads, set strict rules for redacting secrets and personal data, limiting access, and retaining records.

## A receipt is not the truth

Think about a letter sealed with wax. An intact seal is evidence that the envelope wasn’t opened in transit. It says nothing about whether the letter inside is honest, accurate, or complete. A cryptographic receipt works the same way.

![A two-panel comparison is headed “CAN BIND” and “CANNOT PROVE.” The CAN BIND panel lists “Run identifier,” “Journal count + head,” “Lineage count + head,” “Optional audit-chain range,” and “Signing key.” The CANNOT PROVE panel lists “Correct work,” “True source data,” “Unlogged events,” and “Good faith.” The plate separates recorded fields a receipt can bind from facts it cannot establish.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/bernstein-receipt-boundaries.png)

A [signed receipt](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L698-L724) binds [recorded fields](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L308-L332); it doesn’t prove the work was correct or all actions were logged.

Bernstein’s [deterministic orchestration](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/architecture/WHY%5FDETERMINISTIC.md?ref=groktop.us) makes control flow repeatable, which helps replay a run. It cannot make large language model (LLM) token sampling deterministic or force external APIs to return identical responses next week.

A signed [run receipt](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L698-L724) binds a [run identifier](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/replay/run%5Freceipt.py?ref=groktop.us#L308-L332), the journal event count and head, the lineage spine’s entry count and head, and, when present, an audit-chain range. A verifier can check those fields against the record. The receipt doesn’t prove the agent’s work was correct or that the person running it acted in good faith.

You see the same limitation whether you look at data lineage, audit chains, or content credentials.

[Artifact lineage](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/concepts/artifact-lineage.md?ref=groktop.us) binds inputs to outputs, but it cannot tell you whether the source prompt began with flawed assumptions. An [HMAC audit chain](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/security/audit-log.md?ref=groktop.us) can reveal tampering in recorded entries, but it remains blind to actions that avoided logging entirely.

The [Coalition for Content Provenance and Authenticity (C2PA)](https://c2pa.org/?ref=groktop.us) publishes an open [specification](https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA%5FSpecification.html?ref=groktop.us) for signed content credentials. Bernstein’s [credential command](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/cli/commands/credential%5Fcmd.py?ref=groktop.us#L1-L18) writes a [custom C2PA 2.2 manifest](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/lineage/c2pa.py?ref=groktop.us#L1-L18) to a separate `.c2pa.json` sidecar, projected from the lineage spine, rather than embedding it in the media file. A valid signature identifies the key that signed the manifest; it cannot make the underlying content true.

Bernstein’s [OpenTelemetry export](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/observability/otlp-export.md?plain=1&ref=groktop.us#L41-L53) is opt-in. Forwarding spans to a collector is plumbing, not incident management.

## When evidence meets law and policy

A receipt can show what the system recorded. It cannot decide whether that evidence satisfies an organization’s legal duties. Bernstein’s documentation for the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 42001 [evidence pack](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/iso42001-mapping.md?plain=1&ref=groktop.us#L16-L21) is explicit: the project cannot certify anyone or claim conformance.

![A three-panel evidence map distinguishes three frameworks. Panel one reads “NIST AI RMF” (the National Institute of Standards and Technology’s AI Risk Management Framework), “MAP subcategories,” “3 of 18,” and “marked Covered.” Panel two reads “EU AI Act” (the European Union’s Artificial Intelligence Act), “Article 11: technical documentation,” “Article 12: event logging,” and “Article 14: human oversight.” Panel three reads “ISO/IEC 42001,” “Evidence pack,” “No certification claim,” and “No conformance claim.” The panels separate a software coverage map, regulatory documentation and logging duties, human oversight, and a project evidence pack’s limits.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/bernstein-evidence-law-policy.png)

[Bernstein’s map](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/nist-ai-rmf-mapping.md?ref=groktop.us#L73-L90) marks 3 of 18 MAP subcategories Covered; [Article 14’s human-oversight duty](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us) is separate.

Bernstein’s [mapping](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/nist-ai-rmf-mapping.md?ref=groktop.us) to the National Institute of Standards and Technology’s (NIST) [AI Risk Management Framework (AI RMF)](https://doi.org/10.6028/NIST.AI.100-1?ref=groktop.us) covers all four functions: Govern, Map, Measure, and Manage. The project’s own table marks only [three of 18 MAP subcategories](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/nist-ai-rmf-mapping.md?ref=groktop.us#L73-L90) as Covered. That is a thin map of software support, not an independent risk assessment. Software cannot set acceptable risk thresholds, evaluate societal impacts, or decide how an organization manages bias.

Regulatory compliance runs into the same friction under the [European Union’s Artificial Intelligence Act (EU AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us). For high-risk AI systems, [Article 11](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us#art%5F11) sets technical-documentation requirements, and [Article 12](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us#art%5F12) requires automatic event recording.

The project’s [Article 12 bundle](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/eu-ai-act-article-12-bundle.md?plain=1&ref=groktop.us#L235-L244) lists its limits: it doesn’t generate [Article 43](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us#art%5F43) paperwork itself. A separate [bernstein compliance assess](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/compliance.md?ref=groktop.us#L95-L108) command produces the Annex IV technical document and the Article 43 conformity-assessment record.

The bundle’s records can support an assessment, but they do not establish that an organization meets its legal duties. [Article 14](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=groktop.us#art%5F14)’s human-oversight requirements are separate.

If someone is asked to approve a five-hundred-line code diff without enough time to review it or any practical authority to intervene, a logged approval proves only that a button was clicked. Real oversight requires context, time, authority, and institutional backing to pull the emergency brake.

Certification to [ISO/IEC 42001](https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html?ref=groktop.us) is voluntary. An independent certification body can confirm that an organization’s AI management system meets the standard, but that certificate does not establish that a particular tool complies.

Bernstein’s [evidence pack](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/iso42001-mapping.md?plain=1&ref=groktop.us#L3-L21) derives per-control evidence from an operator’s own audit chain, but [offline re-derivation](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/iso42001-mapping.md?plain=1&ref=groktop.us#L9-L12) of those mappings in `bernstein audit verify` is still [planned](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/compliance/iso42001-mapping.md?plain=1&ref=groktop.us#L16-L21). The pack can support an assessment, but it doesn’t certify an organization or establish its conformance. Each organization still has to decide what that evidence means for its own legal and governance obligations.

## Where the control actually stops

Bernstein includes login and callback routes for [OpenID Connect (OIDC)](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/auth.py?ref=groktop.us#L196-L236), plus an assertion-consumer route for [Security Assertion Markup Language (SAML)](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/auth.py?ref=groktop.us#L310-L321). Each requires its provider to be enabled in server configuration. These routes are entry points, not working identity-provider integrations by themselves.

![A neutral four-panel map reads: AUTHENTICATION, “Routes exist”; USER ACCOUNTS, “Lookup + deactivate” and “No create, filter, or bulk operations”; SECRETS, “Developer tokens: keychain or encrypted file” and “Provider keys: separate broker”; POLICY, “Evaluation hooks exist” and “No live caller at reviewed commit.” The map distinguishes available authentication, partial account provisioning, separate credential paths, and policy hooks without a caller in the reviewed code.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/bernstein-control-boundaries.png)

The repository contains both hooks, but their verdicts never reach a live permission decision at the [reviewed commit](https://github.com/sipyourdrink-ltd/bernstein/commit/bd55eeeb5174c8362eeee87828a193f7ca456722?ref=groktop.us).

User provisioning through the [System for Cross-domain Identity Management (SCIM)](https://www.rfc-editor.org/rfc/rfc7644?ref=groktop.us) protocol is partial. Bernstein supports [listing users](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L393), [fetching a user](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L434), [soft deletion](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L472), and a [limited update that only deactivates an account](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L504). There isn’t a route to create a user. The [service-provider configuration](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L297-L300) reports bulk operations and filtering as unsupported, and [filter requests return 501 (Not Implemented)](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/routes/scim.py?ref=groktop.us#L411-L416). That gives you lookup and deactivation, not a full provisioning lifecycle.

The [developer-credential vault](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/operations/secrets.md?plain=1&ref=groktop.us#L21-L30) stores human-supplied tokens in the operating-system keychain by default, or in an encrypted file on headless machines. A separate [secrets broker](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/security/secrets%5Fbroker.py?ref=groktop.us#L257-L367) provides native backends for provider keys in HashiCorp Vault, Amazon Web Services (AWS) Secrets Manager, and Google Cloud Secret Manager.

The most critical gap is policy enforcement. Bernstein has evaluation hooks for Open Policy Agent (OPA) and Cedar. The [OPA hook](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/security/external%5Fpolicy%5Fhook.py?ref=groktop.us#L320-L338) shells out to `opa eval`; the [Cedar hook](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/src/bernstein/core/security/external%5Fpolicy%5Fhook.py?ref=groktop.us#L442-L443) implements a subset parser, not a full Cedar engine.

At the [reviewed commit](https://github.com/sipyourdrink-ltd/bernstein/commit/bd55eeeb5174c8362eeee87828a193f7ca456722?ref=groktop.us), no live execution path calls either hook. Open [issue #4912](https://github.com/sipyourdrink-ltd/bernstein/issues/4912?ref=groktop.us) tracks the missing decision path. Until a live run invokes the appropriate hook and records its verdict, its presence in the repository is not proof that policy is enforced.

Deployment architecture and application wiring dictate which checks a running agent actually encounters. That is the practical reality behind [repository readiness](https://www.groktop.us/repo-readiness/).

## The person who still has to decide

Imagine an automated run landing on a maintainer’s desk with a signed receipt showing which gates ran. The machine still can’t decide whether the change is wise.

![A worker hands a signed receipt to a maintainer who chooses between stop and merge.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/07-accountability.png)

A signed receipt gives the maintainer evidence to inspect, but leaves the stop-or-merge judgment with them.

Bernstein’s [volunteer-compute guide](https://github.com/sipyourdrink-ltd/bernstein/blob/bd55eeeb5174c8362eeee87828a193f7ca456722/docs/volunteer/project-guide.md?plain=1&ref=groktop.us#L88-L89) makes that boundary explicit: a signed receipt can attest that declared gates ran, but it doesn’t prove a code change is desirable. Maintainers still have to review the proposed diff and decide whether to merge it.

Every enterprise AI workflow needs an unambiguous human owner. Name the person accountable for risk and for the boundary between acceptable operations and forbidden actions. Give that person the authority to stop a runaway agent without having to schedule a committee meeting.

If evidence automation saves senior engineers and operators time, invest that capacity in process improvement, deeper root-cause investigations, and judgment, not higher throughput quotas. That’s the core argument in [my piece on human labor in AI governance](https://www.groktop.us/ai-governance-human-work/).

## Only then grant more autonomy

All of this engineering exists for a simple reason: figuring out how much leash to give an agent.

![Four left-to-right stages read “BOUNDED SCOPE,” “TEST CONTROLS UNDER FAILURE,” “VERIFY THE EVIDENCE TRAIL,” and “EXPAND AUTHORITY,” joined by three dotted arrows. A band beneath all four stages reads “ACCOUNTABLE HUMAN CAN INTERVENE.” The sequence places bounded testing and evidence verification before expanded authority, while keeping a responsible person able to intervene throughout.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/09/bernstein-earned-autonomy.png)

The accountable human can intervene at every stage, not only after authority expands.

Before you give an AI system permission to write directly to production databases or interact autonomously with customers, run through the seven questions above. Verify the active policy digest, confirm the live route forces execution through the check, inspect the recorded evidence, and ensure an accountable human has the real authority to intervene.

Expand an agent’s authority in deliberate, bounded steps only after its controls have held under simulated failure and the audit trail survives external scrutiny. Autonomy without an evidence trail is just reckless delegation.

Policy as code gives you intent. But unless you can prove that the gate was wired into the live path, ran before the action, and left a verifiable trail, you haven’t governed your systems. You’re just taking an autonomous model’s word for it.