Agentic AI governance is a review record, not a review committee

Once an agent can change a customer record, an invoice or an entitlement, governance stops being a policy PDF and becomes a question of artifacts: what was proposed, which rule judged it, who approved it, on what evidence, and can any of that be altered after the fact.

This is the framework we build against: seven pillars, a role split, and the six questions an auditor will actually ask. It pairs with our threat-model page on agentic AI security, which covers the attack side of the same boundary.

[ 01 / 03 ] · FRAMEWORK // seven pillars //sha 9f2c1a

A written scope per agent

Name the systems of record it may touch, the objects and fields inside them, and the outcomes it is accountable for. Governance starts as an inventory, not a policy document: an agent with no declared scope cannot be reviewed, rate-limited or revoked.

Policy as code, not policy as prose

Field-level rules, schema validation, value bounds and immutability windows live in version control and run on every proposed change. Each change set gets a deterministic verdict — allow, hold for review, or reject — and the rule that produced it is quotable in a review.

Approval routed by risk class

Classify changes rather than reviewing everything the same way. Low-impact, well-evidenced, in-policy edits can auto-merge; revenue, identity, permissions and financial fields require a named human approver on that specific change.

Evidence as the unit of trust

Every proposed value cites its source — message ID, document span, query result. Reviewers check citations instead of trusting a summary, and an auditor can re-derive the value months later without asking the model what it was thinking.

Hash-chained, append-only audit

Before/after snapshot, evidence references, policy verdict, approver and timestamp, each entry committing to the previous one with sha256. Deletion or backdating breaks the chain, so the record is evidence rather than a log you have to vouch for.

Separation of duties at the credential

The component that reasons must not be the component that commits. A narrow merge worker holds the only write credential, which turns an autonomy question into an authorization boundary you can test.

Measured autonomy, reviewed on a cadence

Start in shadow mode, measure the approval rate per policy class on real proposals, and grant auto-merge only where the data supports it. Re-read the numbers on a schedule and revoke on drift — autonomy is a grant, not a setting.

[ 02 / 03 ] · ROLES // who answers for what //sha 3ad8f0

Five roles, no shared accountability

Agent ownerDeclares scope, owns the approval rate, answers for incidents in their agent's lane.

Policy ownerWrites and versions the rules as code; reviews change requests to the rules themselves.

ReviewerApproves or rejects individual change sets against evidence — never a batch count.

AuditorReads the chain without write access, samples entries, re-derives values from evidence.

PlatformHolds the merge credential, enforces rate and scope limits, keeps the chain intact.

policy.yaml — governance as code

agent: revops-assistant
scope: crm/opportunity, crm/account

rules:
  - field: amount
    approval: human, named
    evidence: required
  - field: close_date
    approval: auto if in-policy
    window: not after period close
  - field: owner_id
    approval: deny — out of scope

limits: 40 changes / hour, 1 batch / run

every merge appends: diff · evidence · verdict · approver
entry N commits to entry N-1 (sha256)

[ 03 / 03 ] · AUDIT // six questions, six artifacts //sha c1de77

Which agents can write to which fields today?

Answered by the scope inventory (G1).

What rule allowed this change?

Answered by the policy verdict stored with the entry (G2).

Who approved it, and on what basis?

Answered by approver plus evidence references (G3, G4).

Could the record have been altered afterwards?

Answered by the hash chain (G5).

What is the blast radius if the agent is compromised?

Answered by the credential model (G6).

Is autonomy still justified?

Answered by the per-class approval rate (G7).

Governance that produces artifacts, not assurances.

ActionsLedger runs policy as code on every proposed change, routes approval by risk class, and appends a hash-chained entry per merge — so the answers already exist when someone asks.

Start for free Read the threat model