Platform-generated events vs offline-verifiable evidence

Every platform that shipped agent features this October promised a record of what those agents did. GitLab announced one on 6 October, inside what it calls the foundation for a governed software factory: goal-driven agentic workflows, a governed artifact home next to source code, a dependency firewall, per-job scoped secrets, and what the press release describes as "an evidence chain that records how changes move from intent to production". It is a good idea. It is worth asking one question of it: who generated the chain, and can you verify it without the platform's help?

What a platform-generated record can and cannot prove

A record generated by the same platform that runs the work records what that platform saw, under that platform's identity. GitLab's own description makes the arrangement explicit: custom flows run "under the same identity, policy, and evidence chain".

That record is useful. For a change that never leaves GitLab it is a convenient place to look, and the new controls around it - Artifact Central, the Dependency Firewall, the scoped Secrets Manager - are real controls doing real work. The claim here is narrower than "GitLab has no governance": GitLab's evidence is platform-scoped and self-generated.

What it cannot do, by construction, is stand independent of the system it reports on. If the platform is wrong, breached, or simply unavailable, the record goes with it, and re-checking it means asking the same vendor to inspect its own logs. An auditor, a regulator, or a board is not asking whether the platform believes itself. They are asking whether anyone else can check. Independence cannot be added to a log after the fact; it follows from who holds the artefact and what they can run against it.

A platform's evidence chain records what that platform saw. Modulo records what happened - across every tool a change touches - in a chain you can verify yourself.

The provenance ladder: observed, derived, self-reported

A record is only as good as the reader's ability to tell how each entry was obtained. There are three ways a value enters a record:

• Observed - the system measured it. A gate evaluated an output and the decision was written; a connector read the merge state from the API. It happened, and the record saw it happen.
• Derived - a value computed from observed facts: a score checked against a threshold, a cost roll-up, a status aggregated from node states. Re-derivable from what was observed.
• Self-reported - an agent's own account of what it did: a summary, a claim that the tests passed, a status an agent set on its own work.

These three must never collapse into one undifferentiated stream. A reader who cannot tell an agent's claim from a measurement will eventually act on the claim as though it were one, and that is how "the agent said the tests passed" becomes an incident. Any record worth trusting grades every entry by provenance, so a reader can tell what was measured from what was claimed.

What offline-verifiable means

Offline-verifiable evidence is a record a party holding only the artefact and a pre-published verification key can check: verify authorship, re-verify the embedded audit chain, and re-derive every derived value, with no vendor service involved.

Four properties make that possible:

1. A hash chain. Every entry commits to the entry before it, so editing one entry breaks every hash after it. Tampering is detectable, not merely discouraged.
2. An export you hold. The record leaves the product as an artefact, not as a view inside someone's interface.
3. Your own database. Modulo runs on your infrastructure against your own Postgres, sends no telemetry, and is air-gap capable, so there is no vendor-side copy to request and no service to ask.
4. A key published in advance. The verification key exists before the record does. A key minted after the fact proves nothing about the entries written before it.

None of these ask you to trust the vendor at verification time. The check runs against the artefact, offline, by whoever you choose.

Why OWASP's recommendations land here

The OWASP GenAI Security Project published its Q3 2026 exploit roundup on 8 October. Its call to action on the largest incident reads: "Correlate package-service, identity, network and tool logs by run ID, and test a stop mechanism that revokes both credentials and network access."

Correlation by run ID is only the start. For a joined record to mean anything to someone outside the platform that wrote it, it has to be checkable without that platform, otherwise the recommendation collapses into a promise that the logs say what they say. The roundup's other asks - per-run credentials, scope enforced through controls the agent cannot rewrite - are controls a run can enforce; whether they held is what the record has to answer, offline and without the vendor. What the OWASP Q3 2026 agent roundup means if you've put agents in your delivery pipeline walks each incident and the control that bounds it.

How Modulo produces it

Modulo records every governance event - run start, agent dispatch, human decision, gate outcome - in a hash-chained, append-only log inside your own instance, and the log is always written. Every entry carries its provenance grade: observed, derived, or self-reported. Export the record, hand it to a third party with the pre-published verification key, and the verification runs without Modulo in the room.

That is the work the phrase "offline-verifiable evidence" is doing. A platform can always give you more of its own logs. It cannot give you a record that no longer depends on it.

For the dimension-by-dimension version of this argument, see Modulo vs GitLab's governed software factory.