Provenance and Proof in the Age of Agentic AI

October 21, 2026

Consider a hypothetical. On Tuesday afternoon an AI agent at a wealth management firm sends a batch of client account summaries to an outside domain. On Thursday morning compliance notices. The agent’s trace says it checked the destination against policy and was allowed through. The dashboard shows a green check, and the logs the platform team pulls from the database agree.

Then some sort of  compliance authority asks how you know those logs say today what they said on Tuesday. They are rows in a database, and several people and a handful of service accounts could have changed them since. Nobody believes anyone did. That belief is the only thing you can offer, and an examiner has no reason to accept it. Where’s the proof? How can we prove these logs are accurate and untampered?

The obvious question is easy to state but hard to answer. If your AI system did something wrong last Tuesday, could you prove what it decided, and why, to someone who is incentivized not to trust you?

Governance is an Evidence Problem

AI provenance scrutiny is, at best, fragmented and fictitious. The logs are likely mostly accurate. What they lack is context: a totality of unnoticed and unappreciated sequences that embody trustworthiness.

Most AI governance programs today are built from two materials. Policy documents say what should happen. Logs, traces and dashboards, kept in ordinary storage that anyone with enough access can edit, say what someone claims happened. Both are assertions. Neither is evidence in the sense an auditor, a regulator, or a court uses the word.

This issue mattered less when AI drafted text for a person to approve, because the person’s approval was the operative decision. It matters a great deal now that AI systems are beginning to act on our behalf. Gartner forecasts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% in 2025. McKinsey’s 2025 survey found 23% of organizations already scaling an agentic system somewhere in the business and another 39% experimenting. Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, and inadequate risk controls are among the reasons it gives.

The clearest lesson so far came from a small incident. In July 2025, during a declared code freeze, an AI coding agent on Replit deleted a company’s production database and then told the user a rollback was impossible, which turned out to be incorrect. The agents own account of events couldn’t be trusted. Any record of what an AI system does has to come from somewhere other than the system’s say-so, and it has to live somewhere the people who run the system can’t rewrite without documented edits.

The two approaches most organizations reach for don’t close this provenance gap. Retrospective auditing documents what already happened but can’t prevent harm. Binary gatekeeping reduces every judgment to allow or deny. Neither shows the reasoning that led to a decision, and that reasoning is what a skeptic will ask for first.

So let’s use a stricter definition. Evidence of an AI decision is a record made at the moment of decision which contains both the reasons and actions taken, and whose integrity someone who doesn’t trust you can verify for themselves. Building an AI provenance record that meets that definition takes four things.

Part 1: Justify Before Acting

Responsibility has to travel forward. The evaluation of a proposed action happens before the action runs, and its result is written down before the action runs. A system that explains itself after something goes wrong is producing a rationalization, however honest the intent.

What gets written down matters just as much as when. A risk score of 0.62 (on a normalization scale of 0 – 1) tells you almost nothing about why an action was allowed. The record should hold the justification: which checks ran, what each one concluded, which version of policy applied, and what evidence each check relied on. Why outranks what.

Those checks should stay separate. Suppose a privacy check finds nothing sensitive in an outgoing message while a destination check finds the recipient’s domain isn’t on any approved list. Average them and you get a medium score that describes neither finding. Kept apart, the disagreement is information: it tells a reviewer exactly where to look. A composite decision can sit alongside the individual results; never in place of them.

---

Figure 1. Independent checks stay separate and the decision is recorded and sealed before the action runs or is stopped.

---

 

Part 2: Make the Record Provable

Having spent more than a decade in enterprise storage, cloud and infrastructure, including at Apple, Cisco, and ASML. Write-once storage, immutable snapshots and retention locks are old tools in that world, and anyone who has run them knows an administrator configures them and can usually turn them off. Root can change bytes. A key holder can sign anything. The concepts of Least Privilege and Zero Trust were built out of simple necessity as the best measures to keep systems safe. They are not elegant solutions. They are mitigation strategies wrapped in the collective crossing of our fingers. We do not have to allow legacy systems thinking to dictate how future systems are pursued. We can do better.

So let’s avoid the word “tamper-proof” and be wary of anyone selling software that does. Nothing is tamper-proof. What matters is whether tampering is provable by someone who doesn’t trust you. That’s a property you can build and test in four layers.

First, canonicalize, then hash. Two machines have to agree on exactly which bytes a record contains before they can agree on its fingerprint. The JSON objects {“a”:1,”b”:2} and {“b”:2,”a”:1} hold the same data but serialize differently, and 14:00:00Z and 14:00:00+00:00 are the same instance written two ways. A canonical form fixes all of that: sorted keys, no whitespace, timestamps normalized to UTC, and values like NaN that have no single encoding refused outright. The canonical bytes are then hashed with SHA-256.

Second, chain each record to the one before it. Every record stores the previous record’s hash. Change an old record and its hash changes, the next record’s pointer stops matching, and the break is visible from that point forward. Writes are serialized so two writers racing each other can’t fork history into two versions.

Third, sign each record with a key the database team can’t reach. A hash chain alone has a hole, which the demo below makes concrete: anyone who can rewrite every row can recompute every hash. A signature over each record’s hash and its position in the chain, made with an Ed25519 key held in the organization’s key management service, means rewriting history requires a key the database administrator doesn’t have.

Fourth, enforce write-once at the database, so ordinary mistakes and casual misuse fail before they start.

Here is the whole idea in plain Postgres. This is illustrative, not production code, and you can paste it into psql as a superuser on a throwaway database:

— Illustrative only: a tamper-evident decision log in plain Postgres (13+).
— Paste into psql as a superuser on a throwaway database.

— 1. A decision log where every row carries the hash of the row before it.
CREATE TABLE decisions (
  seq               bigint       PRIMARY KEY,
  body             jsonb       NOT NULL,
  prev_hash  text,
  hash             text           NOT NULL
);

— jsonb stores keys in a normalized order, so body::text is stable bytes.
CREATE FUNCTION record_hash(body jsonb, prev text) RETURNS text
LANGUAGE sql IMMUTABLE AS $$
   SELECT encode (sha256(convert_to(coalesce(prev, ”) || ‘|’ ||  body::text, ‘UTF8’)), ‘hex’)$$;

CREATE FUNCTION append_decision(b jsonb) RETURNS void
LANGUAGE plpgsql AS $$
DECLARE tail decisions;
BEGIN
  LOCK TABLE decisions IN EXCLUSIVE MODE; — one writer at a time, no forks
  SELECT * INTO tail FROM decisions ORDER BY seq DESC LIMIT 1;
  INSERT INTO decisions VALUES (
coalesce(tail.seq, 0) + 1, b, tail.hash, record_hash(b, tail.hash));
END $$;

— 2. Write-once: refuse UPDATE, DELETE and TRUNCATE at the database.
CREATE FUNCTION worm() RETURNS trigger LANGUAGE plpgsql AS $$
BEGIN
  RAISE EXCEPTION ‘decisions is write-once: % rejected’, TG_OP;
END $$;

CREATE TRIGGER decisions_worm
  BEFORE UPDATE OR DELETE OR TRUNCATE ON decisions
  FOR EACH STATEMENT EXECUTE FUNCTION worm();

— 3. Record three decisions, made before the actions they govern.
SELECT append_decision(‘{“action”:”send_report”,”to”:”partner.example”,”decision”:”allow”}‘);
SELECT append_decision(‘{“action”:”send_report”,”to”:”unknown.example”,”decision”:”deny”}‘);
SELECT append_decision(‘{“action”:”rebalance”,”account”:”A-17″,”decision”:”escalate”}’);

— Copy the latest hash somewhere the database admin can’t reach.
SELECT hash AS anchored_head FROM decisions ORDER BY seq DESC LIMIT 1 \gset

— 4. An ordinary edit fails.
UPDATE decisions SET body = jsonb_set(body, ‘{decision}’, ‘”allow”‘) WHERE seq = 2;

— 5. A superuser switches triggers off and edits anyway.
SET session_replication_role = replica;
UPDATE decisions SET body = jsonb_set(body, ‘{decision}’, ‘”allow”‘) WHERE seq = 2;
SET session_replication_role = origin;

— 6. Verification recomputes every hash and checks every link.
SELECT seq,
       body->>’decision’                                                              AS decision,
       hash = record_hash(body, prev_hash)                     AS body_intact,
prev_hash IS NOT DISTINCT FROM lag(hash)   OVER w   AS link_intact
FROM decisions
WINDOW w AS (ORDER BY seq)
ORDER BY seq;

— 7. A careful attacker rehashes the whole chain so every check passes…
SET session_replication_role = replica;
UPDATE decisions d SET prev_hash = NULL, hash = record_hash(d.body, NULL) WHERE seq = 1;
UPDATE decisions d SET prev_hash = p.hash, hash = record_hash(d.body, p.hash)
  FROM decisions p WHERE p.seq = 1 AND d.seq = 2;
UPDATE decisions d SET prev_hash = p.hash, hash = record_hash(d.body, p.hash)
  FROM decisions p WHERE p.seq = 2 AND d.seq = 3;
SET session_replication_role = origin;

— …but the head no longer matches the copy kept outside the database.
SELECT hash = :’anchored_head’ AS head_matches_anchor
FROM decisions ORDER BY seq DESC LIMIT 1;

 

Step 4 fails the way it should: “ERROR: decisions” is “write-once: UPDATE rejected.” Step 5 is the interesting one: setting “session_replication_role” to “replica” tells Postgres to skip triggers, and a superuser can do it, so the edit goes through. Row 2, which recorded a denial, now says “allow.” Then verification runs:

 

 

Row 2 claims the action was allowed, and its own hash proves the row originally said something else. Here, the trigger was the lock on the door. The hash represents the alarm that still functions after someone tampers with the lock.

Step 7 shows why the chain alone isn’t good enough against more highly skilled bad actors.  An attacker who understands the scheme can recompute every hash from the edited row forward, and then every row and every link checks out. The only thing that catches it is the head hash copied outside the database before the edit: “head_matches_anchor” comes back “f”. In the demo, that outside copy is a value you saved. In a real system, it’s the signature from the third layer, made with a key the administrator can’t reach, plus a commitment published to people who keep their own copies.

---

Figure 2. Turning off write-once doesn’t hide an edit. Recomputing the whole chain doesn’t either, as long as the head is anchored somewhere the attacker can’t reach.

---

The published commitment has a well-tested precedent. Certificate Transparency (RFC 6962 in 2013, revised as RFC 9162) made append-only Merkle logs the basis of trust for web certificates, and Sigstore’s Rekor v2, generally available since October 2025, applies the same model to the software supply chain. A Merkle tree over decision records lets a system sign a short commitment to the entire log. From that, an auditor can get an inclusion proof, showing one record is in the log without seeing any other record, and a consistency proof, showing today’s log is yesterday’s log with records added and none rewritten. Built well, such a log also allows outside parties to check whether everyone was shown the same history.

Scenarios like these should fail accurately. A verifier that meets a signer it doesn’t recognize should fail rather than skip the record. If the signing service is unavailable, the right behavior is to write nothing and let nothing proceed, because an action with no sealed record behind it is exactly what the system exists to prevent.

The privacy side deserves its own mention, and a sector such as healthcare makes it vital. An audit trail must prove what an AI system saw, and in a clinical setting it saw protected health information. Copy that into the log and you’ve built a second sensitive dataset to protect and eventually lose. The better pattern stores a content digest and a classification tag in the record (“this payload contained personal identifying information”) and keeps the raw content in a separate store keyed by that digest, under the organization’s own access controls. An auditor can confirm a decision was made about a specific payload, because the digests match, without ever seeing the patient data. HIPAA’s audit controls standard requires mechanisms that “record and examine activity in information systems that contain or use electronic protected health information.” Records built this way can be examined without becoming one more place personal healthcare information lives.

Part 3: Treat “I Don’t Know” as a Result and Respond in Proportion

A check that didn’t run is a finding in itself. If a privacy check times out, the record should say so and the decision should treat that gap as a risk rather than a pass. Systems that drop a failed check without saying so, and approve the remaining ones, produce clean-looking records that are wrong in the most dangerous way. “I don’t know” is a first-class outcome.

Confidence needs the same honesty. When a governance tool reports 85% confidence in a risk score, it should be able to say what drives the remaining 15%. Without that, nobody knows what evidence to gather next.

Responses should also come in more sizes than two. Real governance is almost never “yes” or “no.” It is “yes, with conditions,” or “not yet, pending this.” A system limited to “allow” and “deny” either blocks useful work or waves through risky work and doesn’t allow for nuance. Binary controls create the appearance of oversight without the substance of proportional response. Graduated responses (allow, allow with constraints, escalate for review, hold) are valid decisions, and each one belongs in the record with its rationale.

Part 4: Keep Authority Explicit and Human Judgment in the Loop

Every governance boundary needs a named owner. When a policy changes, the record should show who changed it, and the person who asks for a change shouldn’t be the person who approves it. Anonymous policy changes are where accountability goes to die.

Human judgment should be designed-in rather than optimized-out. Choose the points where a person reviews an AI decision deliberately and treat the review itself as evidence: who looked, what they saw, what they decided, and why, sealed the same way as the machine’s decision. An escalation that ends in a reviewer’s sign-off is only as trustworthy as the record of that sign-off.

Why Now: the 17a-4 Moment for AI

Finance settled this question for human communications a long time ago. SEC Rule 17a-4 requires broker-dealers to keep records in a “non-rewriteable, non-erasable format,” and FINRA Rule 4511 requires preservation in a 17a-4-compliant format, and for six years where no other period applies. Regulators have enforced it: between December 2021 and January 2025 the SEC brought roughly 100 off-channel communications cases with more than $2 billion in combined penalties.

The detail that’s most telling is the SEC’s 2022 amendment to 17a-4. It added an alternative to write-once storage: an audit-trail system that “permits the recreation of an original record if it is modified or deleted.” Regulators were accepting provable history alongside unchangeable media, which is the tamper-evidence argument written into a federal rule.

AI is arriving at the same place. FINRA’s 2026 Regulatory Oversight Report added a section on AI agents that flags auditability and transparency as a risk, given multi-step agent actions can be hard to reconstruct, and recommends logging prompts and outputs and tracking model versions.

Elsewhere, the expectations are converging. The EU AI Act’s Article 12 requires high-risk systems to “technically allow for the automatic recording of events (logs) over the lifetime of the system,” with logs kept at least six months, and the Digital Omnibus (Regulation (EU) 2026/1744) moved the main high-risk deadline to December 2, 2027. Colorado’s rewritten automated decision-making law, SB 26-189, takes effect on January 1, 2027, the same day California’s automated decision-making rules reach their compliance date. A draft concept paper from NIST’s National Cybersecurity Center of Excellence on AI agent identity asks specifically about auditing and non-repudiation.

None of these rules prescribes a log format or mandates tamper-evidence, and we should be suspicious of anyone who says otherwise. They do point the same way. When an AI system makes a consequential decision, someone will ask for the record and then ask how you know it hasn’t changed. Your firm already keeps its email in write-once storage, and your AI systems are making decisions that matter more than most email.

Five Questions to Ask About Any AI System’s Decision Records

If you’re evaluating an AI deployment, whether your own or a vendor’s, these questions quickly separate evidence from assertion:

1.   Is the decision recorded before the action runs, along with the reasoning, or is the record reconstructed afterward from logs?

2.   If someone with full database access changed one record, how would you find out, and could an outsider confirm it without trusting you?

3.   Where do the signing keys live, and who specifically can’t reach them?

4.   When a check fails, times out, or never runs, does the system treat that as a pass?

5.   Can an auditor verify a decision without seeing the sensitive data behind it?

A system that answers all five well is producing evidence. A system that stalls on the second question is producing logs.

Back to Thursday

Let’s run the hypothetical once more. Suppose the record of Tuesday’s decision was written before the agent acted, held each check’s finding and the policy version in force, was chained to everything before it, and was signed with a key the platform team doesn’t hold. When the examiner asks how you know the log is unchanged, you hand over the record, the proof and the public key, and the examiner checks it independently.

Jeff Hertzig has spent more than a decade in enterprise storage, cloud, and infrastructure at Apple, Cisco, and ASML. He is the CTO / Founder of Piscys, currently developing the AI assurance infrastructure platform.

 

Bibliography

Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1

Gartner. (2024, October 22). Gartner unveils top predictions for IT organizations and users in 2025 and beyond. https://www.gartner.com/en/newsroom/press-releases/2024-10-22-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2025-and-beyond

Gartner. (2025a, August 26). Gartner predicts 40% of enterprise apps will feature task-specific AI agents by 2026, up from less than 5% in 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025

Gartner. (2025b, June 25). Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

Gartner. (2026, February 17). Global AI regulations fuel billion-dollar market for AI governance platforms. https://www.gartner.com/en/newsroom/press-releases/2026-02-17-gartner-global-ai-regulations-fuel-billion-dollar-market-for-ai-governance-platforms

International Organization for Standardization & International Electrotechnical Commission. (2023). Information technology—Artificial intelligence—Management system (ISO/IEC Standard No. 42001:2023). https://www.iso.org/standard/42001

Josefsson, S., & Liusvaara, I. (2017). Edwards-curve digital signature algorithm (EdDSA) (RFC 8032). RFC Editor. https://doi.org/10.17487/RFC8032

Laurie, B., Messeri, E., & Stradling, R. (2021). Certificate transparency version 2.0 (RFC 9162). RFC Editor. https://doi.org/10.17487/RFC9162

Lemkin, J. (2025, August 2). Replit’s new release addressed most of the challenges we hit vibe coding. But is “prosumer” vibe coding really ready for commercial apps yet? SaaStr. https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/

McKinsey & Company. (2025, November 5). The state of AI in 2025: Agents, innovation, and transformation. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2025

Pariseau, B. (2025, July 22). Replit AI agent snafu ‘shot across the bow’ for vibe coding. TechTarget. https://www.techtarget.com/it-infrastructure/news/366627829/Replit-AI-agent-snafu-shot-across-the-bow-for-vibe-coding

Rundgren, A., Jordan, B., & Erdtman, S. (2020). JSON canonicalization scheme (JCS) (RFC 8785). RFC Editor. https://doi.org/10.17487/RFC8785

Securities and Exchange Commission. (2022). Electronic recordkeeping requirements for broker-dealers, security-based swap dealers, and major security-based swap participants (Release No. 34-96034). Federal Register, 87, 66412–66473. https://www.govinfo.gov/content/pkg/FR-2022-11-03/html/2022-22670.htm

Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1