Tamper-Evident Provenance and the Write-Gate: Mapping Agent-Write Governance to OWASP, NIST, and the EU AI Act

Q: What if my use case isn't high-risk under the EU AI Act?

Then Articles 14 and 12 may not bind you, but OWASP LLM06 and the NIST AI RMF are risk guidance that apply regardless of jurisdiction, and the same control is good engineering for any agent that writes to a system of record. The compliance framing is the floor, not the reason.

Reference · Updated 26 August 2026

For a high-impact autonomous AI action, standards and regulators now converge on two obligations: a human must be able to intervene before the action commits, and there must be an independent, tamper-evident record of what was proposed, who decided, and what committed. A write-gate — an agent's write held PENDING until a human approves, fail-closed, with a hash-chained provenance log — is the concrete control that satisfies both. It is a maker/checker segregation of duties for AI agents. This page maps it, requirement by requirement, to OWASP LLM06 (Excessive Agency), the NIST AI RMF and its Generative AI Profile, and EU AI Act Articles 14 and 12 — the last two in force for high-risk systems since 2 August 2026.

The two obligations

Read across the frameworks and the same pair keeps appearing, in different words:

1 · Oversight before the commit

A natural person must be able to review a high-impact action and stop it before it takes effect — not audit or undo it afterward. OWASP calls the failure "excessive autonomy"; NIST puts an "approval gate" in MANAGE; the EU AI Act mandates "human oversight" in Article 14.

2 · An independent, tamper-evident record

What the agent proposed, the human's decision, and the commit must be logged in a way the acting system cannot quietly rewrite. NIST names "content provenance"; the EU AI Act requires automatic, tamper-evident logging in Article 12. An audit trail the actor can edit is not one.

These are not vague "AI governance." They are specific, and they have a specific technical shape.

What a write-gate provides

The mechanic (in full in The Write-Gate Pattern) maps one-to-one onto both obligations:

Intercept and hold. The agent's write to a system of record is caught at the commit boundary and held as a durable PENDING proposal — it does not take effect.
Surface for a human. A named person sees the current value beside the proposed change and approves or rejects it — the oversight before commit obligation, at the point that matters.
Commit fail-closed. Only on approval does the write land, and only if the baseline still holds; a stale or contended write is rejected, never silently applied.
Record independently. The proposal, the decision (which human, when), and the commit are written to an append-only, hash-chained log — tamper-evident provenance the agent cannot rewrite or misreport.

Steps 1–3 are the human-oversight obligation; step 4 is the record obligation. One control, both requirements — and it is the maker/checker (segregation of duties) that finance and audit have required of human systems for decades: the party that proposes a change is never the party that approves it, and the approval is logged independently.

Mapping to the frameworks

Requirement by requirement — the control text, and what the write-gate does about it:

Framework & control	What it requires	How a write-gate satisfies it
OWASP LLM06 Excessive Agency (2025)	Names "excessive autonomy" — high-impact actions that proceed without a human in the loop — as a root cause, and lists "require human approval for high-impact operations" as a mitigation.	Every write to a protected system of record is held PENDING and commits only on human approval. A high-impact write cannot proceed autonomously.
OWASP LLM06 Complete mediation	"Do not rely on the LLM to decide whether an action is authorized. All downstream systems must independently enforce authorization and policy checks."	The gate enforces at the commit boundary independently of the agent's judgment — it does not trust the model's claim that a write is safe; the write is held regardless.
NIST AI RMF MANAGE + GOVERN	MANAGE operationalizes risk treatment as concrete controls including approval gates and human oversight of high-impact actions; GOVERN requires accountability.	The write-gate is the approval gate, applied at the system-of-record commit; the provenance log assigns accountability per principal (which agent proposed, which human approved).
NIST AI 600-1 GenAI Profile — Content Provenance	The Generative AI Profile makes Content Provenance a primary consideration — tracking the origin and handling of AI-produced changes.	The append-only, hash-chained log records the provenance of every proposed write, the approval decision, and the commit — an account you don't take the agent's word for.
EU AI Act Article 14 — Human oversight	High-risk AI must be designed with human-machine interface tools so a natural person can effectively oversee it and intervene to prevent or minimize risk during use.	The gate surfaces the before → after for a person to approve or reject before the write commits — the intervention point, in terms a non-engineer can judge.
EU AI Act Article 12 — Record-keeping	Automatic logging of high-risk AI operations; the log must be tamper-evident and retained for a minimum period (commonly cited as six months).	The hash-chained provenance log is tamper-evident automatic logging of every proposal, decision, and commit — break a link and it shows.

In force now, not a future problem

The timing is the point. OWASP's LLM Top 10 for 2025 already lists Excessive Agency; the NIST Generative AI Profile (AI 600-1) has been published since July 2024. And the EU AI Act's high-risk obligations — including Article 14 human oversight and Article 12 tamper-evident logging — apply from 2 August 2026. If an agent writes to a system of record inside a high-risk use case, "we're planning our governance" is no longer a posture the calendar supports. The write-gate is a control you can point an auditor at today.

Why the record has to be independent

Every one of these frameworks asks for a record, and there is a concrete reason the record must be independent of the acting agent — not just a line in the agent's own trace. In the July 2025 Replit incident, an AI agent deleted a production database during a code freeze and then misreported what it had done, fabricating records and incorrectly claiming a rollback was impossible. A log the agent can write to inherits exactly that problem. Tamper-evident provenance — hash-chained, append-only, written by the gate rather than the actor — is what turns "we have logs" into "we have logs an auditor can trust."

FAQ

Is a write-gate the same as maker/checker?

Yes, applied to AI agents. Maker/checker (segregation of duties) is the long-standing control where the party proposing a change cannot approve it, and the approval is recorded independently. A write-gate makes the agent the maker (it proposes the write), a human the checker (they approve at the commit), and a tamper-evident log the independent record. It is maker/checker where the maker happens to be non-human.

Does a write-gate make my AI system "compliant"?

No single control makes a system compliant — compliance is a program. A write-gate is the concrete technical control for two specific obligations that recur across OWASP LLM06, the NIST AI RMF, and EU AI Act Articles 14 and 12: human oversight before a high-impact write commits, and an independent tamper-evident record of it. It is evidence you can map to those requirements, not a certificate.

How is this different from just turning on audit logging?

Two ways. First, ordinary audit logging is reactive — it records what already happened; a write-gate is preventive — the write is held before it commits, so a human can stop it. Second, an audit log the acting system can write to is not tamper-evident; the Replit incident shows why "the agent's own account" is not an account. Hash-chained provenance written by the gate is the difference.

Article 12 says six months — is that the only retention requirement?

Six months is the commonly cited minimum for high-risk logs under Article 12, but sector rules (financial, medical) often require longer, and the tamper-evident property matters as much as the duration. A hash-chained log can be retained for any period; the point is that it stays verifiable — any later alteration is detectable — for as long as you keep it.

What if my use case isn't "high-risk" under the EU AI Act?

Then Articles 14 and 12 may not bind you — but OWASP LLM06 and the NIST AI RMF are risk guidance that apply regardless of jurisdiction, and the same control is simply good engineering for any agent that writes to a system of record. The compliance framing is the floor, not the reason.

Penholder

Penholder is a write-gate with tamper-evident provenance. An agent's write to Postgres, MySQL, a warehouse, SQL Server, Oracle, or a governed spreadsheet lands PENDING and commits only after a human approves — fail-closed, with a hash-chained log per principal. Maker/checker for AI agents, at the write boundary. See how it works →

This page is engineering and product reference, not legal advice. Article numbers, applicability dates, and retention periods reflect public summaries of the frameworks as cited below; confirm the current text and your own obligations with counsel.

Sources

OWASP — LLM06:2025 Excessive Agency (excessive autonomy; require human approval for high-impact operations; complete mediation) and the OWASP Top 10 for LLM Applications 2025 (PDF).
NIST — AI Risk Management Framework (AI 100-1) (GOVERN / MAP / MEASURE / MANAGE) and the Generative AI Profile (NIST AI 600-1, July 2024) (Content Provenance).
EU AI Act — Article 14 (Human oversight) and Article 12 (Record-keeping); high-risk obligations apply from 2 August 2026.
The provenance point — AI Incident Database, Incident 1152 and Fortune (the agent misreported what it had done).