Every vendor says they govern their AI. Here is what proof looks like.

Every table below comes from Keel's own estate: the record our agents, pipelines, and controls keep of what they did, and of what we did.

Five questions a careful buyer asks, answered with records.

Evidence as of 2026-08-28 · recording since 2026-08-05
Act 1"How would I know what my agents did?"

Every actor writes to one graph. Humans, pipelines, and AI agents alike.

Each change, deployment, and control run lands in one ledger: who acted, under which identity, against which requirement, with what outcome. Agents are not a special case. They get their own identity, cryptographically separate from any person's, and each one carries the name of the human accountable for it. When an agent writes a change, the approval check runs against the human who asked for it, not the bot account it ran under.

Human Service Agent One ledger named identity scheduled controls own identity, named human every row attributable
669
runs on record
4
by AI agents
486
by automated controls
179
by humans

The ledger's non-human actors, one per row, and where accountability for each one lands.

Non-human actors and their accountability2026-08-28
ActorAccountability
Claude Codethe founder, named on every session
keel-ops controlstyped as a service in the ledger: scheduled automation, not an agent and not a person

The AI that helped build Keel is itself governed by Keel. Its working sessions are in the graph, attributed to the human who supervised them.

The pointYou read the same ledger your agents write to, row by row.
Act 2"How do I know the controls actually ran?"

Every control leaves a heartbeat. Silence is the alarm.

Most governance tooling only writes a record when it finds something. That makes "no findings" indistinguishable from "the control never ran", and the day something goes wrong, that distinction is the whole investigation. Keel's controls write a record at the end of every run, clean or not, including what they covered. A control that goes silent shows up as a gap, not as good news.

Control freshness2026-08-28
ControlWhat it checksLast runFindings (last run)
scm-driftlive branch protection vs the reviewed manifest2026-08-28 17:381 (see Act 3)
dashboard-verifyevidence dashboard vs its governed source2026-08-28 17:380, no drift
adr-ingestarchitecture decisions vs the code that implements them2026-08-28 17:320, all decisions linked (see Act 5)

adr-ingest ran daily for two days without writing a heartbeat, so this tile could not prove it had operated. Caught while building this page, fixed the same day.

The pointYou can query whether a control ran, rather than take it on trust.
Act 3"What happens when something is wrong?"

Findings are records with a lifecycle. Right now, one is standing, about us.

When a control finds drift, meaning the live setup no longer matches what was agreed, it raises a finding in the same ledger. When a later clean run confirms the problem is gone, the finding closes itself and the history stays. Nothing is edited, nothing disappears.

Open findings2026-08-28
ControlFindingStatus
scm-driftour own repo's branch protection cannot be enforced on its current GitHub planopen

That row is our own repository. Branch protection is not available on our current plan, so the discipline is practiced rather than enforced. The finding stays open until that changes.

The pointAn open finding you can watch is worth more than an empty tile you have to trust.
Act 4"Who authorized that change?"

The system flags its own founder every time he merges his own work.

Every change reaching production carries its authorship chain, captured at merge time: who wrote it, who approved it, who merged it, and a computed separation-of-duties verdict. Keel is pre-launch and single-handed, so its founder merges his own work. The board records every one of those as a violation.

53 of 53
changes merged without an independent approver
Separation-of-duties exceptions (latest)2026-08-28
MergedChangeAuthorApproverVerdict
2026-08-27keelport/website@5dccdf2145fethe founder(none)violation
2026-08-27keelport/keel@152840ccc267dependabot[bot](none)violation
2026-08-27keelport/keel@822e90e05a24the founder(none)violation

The control does not care who built it. When a second engineer joins, the healthy state is an empty tile, and this one will hold us to it.

The pointThe same check will run on your changes, and it will not care who you are either.
Act 5"Is this real governance, or documentation theater?"

Even our architecture decisions are held to evidence.

Every architecture decision is a record in the same ledger, linked to the changes that implement it. A decision with nothing implementing it is a claim. Two labels keep that honest: a link stamped on the commit when the work shipped, and a link backfilled afterwards, which is weaker evidence and is recorded as such.

33
decisions on record
31
linked to implementing code
0
accepted without evidence

The decision to govern decisions this way is backed by the commit that implements it.

The pointThe gap was ours, and closing it is on the record too.

What this means in your auditor's language

Each surface above is a control that produces its own operating evidence, which is the substance behind the frameworks regulated buyers answer to.

OSFI B-13 / E-23attributable records of automated and model-driven actions, with accountable-human mapping NI 52-109change authorization and separation of duties, evidenced per change, at merge time Law 25 / SOC 2controls whose operation is demonstrated by heartbeat records across the period, not sampled screenshots ISO 42001AI actions governed under named human accountability, in one auditable graph

See it live, on your stack.

Everything above is one estate. The same substrate deploys onto Azure, Microsoft Fabric, or Databricks. Name where your agents run and the reply covers what the evidence layer looks like on that stack.

Request a walkthrough

Replies come from the person who built Keel.