Guide

Policy Snapshots: Proving Which Rules Your AI Agent Followed

By Dor Sharoni, Founder of Pruvz | 9 min read | Updated August 2026

A policy snapshot is a preserved, immutable copy of the rules, limits, and terms that were in force at the moment an AI agent made a decision, bound to the record of that specific action. It exists because policies change and reviews happen later: a refund decided in March under a $200 auto-approval limit cannot be fairly judged in June against a $100 limit, yet that is exactly what happens when the only policy anyone can consult is the current one. A complete snapshot captures the policy's identity, the exact version, the rules themselves, the inputs the evaluation saw, and the result of every rule, and it is captured once at decision time and read back from stored state, never re-derived by asking the policy system what it thinks now. For AI agents the policy surface is wider than the policy engine: system prompts, retrieved help articles, and hand-edited thresholds steer decisions too, and any text that would have changed the decision had it read differently belongs in the decision-time record.

The question a reviewer actually asks

Imagine a customer disputes a refund an AI agent issued in March, and the case reaches a reviewer in June. The refund policy has changed twice in between: the auto-approval limit moved from $200 to $100 in April, and a new exclusion for subscription renewals landed in May. The reviewer's question is not "does this refund comply with our policy?" It is "did this refund comply with the policy that was in force on March 12, when the agent decided?"

Checking the current policy gets that question wrong in both directions. A $150 refund that was correct under the March rules looks like a violation under the June rules, so a compliant decision gets flagged and a customer relationship gets damaged for nothing. And a decision that broke the March rules can look fine under a later, looser policy, so a real failure passes review. Either way, the review produced a confident answer to the wrong question.

For human decisions this problem is old and manageable: people are slower than policy change, and a person can be asked what they knew. Agents remove both cushions. An agent can take thousands of consequential actions in the window between two policy versions, and it cannot be deposed. The only reliable account of which rules applied is the one written down at decision time. That record is the policy snapshot.

What a policy snapshot is

A policy snapshot is a preserved, immutable copy of the rules, limits, and terms that were in force at the moment an agent made a decision, bound to the record of that specific action. It is one of the core elements of a complete AI agent audit trail, and the one that makes the rest of the trail judgeable: context, decision, and outcome only mean something relative to the rules that governed them.

The defining property is immutability at read time. A snapshot is captured once, when the decision happens, and read back from stored state ever after. It is never re-derived by asking the policy system what it thinks now. A link to the current version of a help center page is not a snapshot. A pointer to refund-policy/latest is not a snapshot. Re-running the policy engine at review time and presenting the result as reconstruction is not a snapshot either, because the engine will happily evaluate the old case against the new rules.

Capturing by value and capturing by reference can both satisfy this, with one condition. Embedding the full policy content in the action record always works. Storing a version identifier or content hash works only if the identified version lives in storage that cannot be rewritten, so the reference will resolve to the same bytes in three years. A reference into a mutable wiki fails that test; a git commit hash or a content-addressed store passes it.

Why "we version our policies" is not enough

Teams that keep policies in version control often assume the problem is solved: the history is right there in git. Versioning is necessary, but it answers a different question. A repository history tells you what versions existed and when they were authored. It does not tell you which version a particular agent actually evaluated for a particular action.

The gap between the two is deployment. A new policy version can be merged at 9:00 and still not be what the agent used at 9:05, because the agent's runtime loads policy on a schedule, caches it, or pulls it from a distribution pipeline with its own lag. Policy distribution systems are explicit about this: Open Policy Agent, a widely used open source policy engine, ships policy to agents as bundles whose manifest carries a revision string precisely so that a running system can report which revision it has actually activated, as opposed to which revision the server most recently published. The snapshot must record what the deciding process actually held, not what the repository says was current.

Database engineering solved the underlying problem years ago and gave it a vocabulary worth borrowing. The SQL:2011 standard introduced system-versioned temporal tables, which keep every historical state of a row and let you query the table "as of" any past moment. Bitemporal designs go further and track two timelines separately: when a fact was true in the world, and when the system recorded it. Policy for AI agents needs exactly this discipline. "What did the refund policy say on March 12?" and "what policy did agent 7 hold in memory on March 12?" are different questions, and after an incident you may need both answered.

Side by side, the two answer different questions:

What you can prove	Version control alone	Policy snapshot
Which policy versions existed, and when they were authored	Yes	Yes
Which version the deciding process actually held	No	Yes
Binding to one specific action record	No	Yes
The inputs the evaluation saw for that case	No	Yes
The result of each rule for that action	No	Yes

What a complete policy snapshot captures

For a consequential action, a snapshot that will survive review needs more than the policy text. Each element exists because a reviewer, months later, will ask for it.

Element	The question it answers
Policy identity	Which policy governed this action: refund policy, claims policy, discount policy?
Version or revision	Which exact version applied: a version label, commit hash, or bundle revision?
The rules themselves	What did that version actually say: content by value, or a hash into immutable storage?
The inputs evaluated	What facts about the case did the evaluation see: amount, customer tier, order age?
Per-rule results	How did each rule come out, so the decision is explainable rather than a bare pass?
Capture time	When was this snapshot taken, on whose clock, relative to the decision?
Binding to the action	Which specific action record does this snapshot belong to, tamper-evidently?

The inputs and per-rule results deserve emphasis, because they are the parts teams most often skip. A snapshot that preserves the policy text but not the inputs proves what the rules were without proving they were applied to the right facts. A snapshot that records "policy passed" without per-rule results forces the reviewer to re-derive the evaluation by hand, against rules they may misread. The strongest snapshot lets a reviewer follow the decision the way the agent's policy check made it: these inputs, through these rules, with this result at each step.

This structure is not hypothetical. Here is the decision-time snapshot from a real evidence packet captured in the Pruvz product demo, exactly as the packet stores it, with every element from the table above in place:

policySnapshot inside a captured evidence packet (abridged: two of four rule results shown)

"policySnapshot": {
  "policyId": "demo-refund-policy",
  "policyVersion": "1",
  "rules": {
    "maxPurchaseAgeDays": 30,
    "maxRefundAmount": { "amount": 100, "currency": "USD" },
    "allowedPaymentStates": ["SETTLED"],
    "ticket": { "ticketRequired": true, "allowedTicketStatuses": ["OPEN", "APPROVED"] }
  },
  "input": {
    "purchasedAtUtc": "2026-06-25T08:00:00Z",
    "evaluatedAtUtc": "2026-07-10T09:14:59Z",
    "refundAmount": { "amount": 42.5, "currency": "USD" },
    "paymentState": "SETTLED",
    "ticketStatus": "OPEN"
  },
  "evaluation": {
    "policyPassed": true,
    "ruleResults": [
      { "ruleId": "purchase-age", "passed": true,
        "explanation": "Purchase is 15 days old, within the 30-day limit." },
      { "ruleId": "refund-amount", "passed": true,
        "explanation": "USD 42.50 is within the USD 100.00 limit." }
    ]
  }
}

The full packet around this snapshot also carries the agent's decision, the executed action, the agent's claim, the independently observed outcome, and the final review state, in an ordered evidence sequence that records when each was captured. It is walked through field by field on the evidence packet page, and the schema it conforms to is published in the open packet schema repository.

The policy surface is bigger than the policy engine

If all of your business rules live in a policy engine, snapshotting is cheap: the engine already has versions, and the work is binding the active version and its evaluation to each action record. Most organizations are not in that position. The rules that actually steer an agent's behavior are spread across surfaces that nobody versions deliberately: help center articles the agent retrieves, macros and playbooks written for human agents, terms and conditions pages, a spreadsheet of thresholds someone updates by hand.

For an AI agent there is one more surface that teams consistently miss: the prompt. If the system prompt says "refunds over $100 require a supervisor," that instruction is policy in every sense that matters, and it changes the way prompts change, which is to say frequently and informally. The same holds for retrieved documents. When an agent's decision was shaped by a knowledge base article it pulled at decision time, the version of that article belongs in the decision-time record. A useful test for scoping the snapshot: any text that, had it read differently, would have changed the agent's decision is part of the policy surface for that action.

Regulators already think in decision-time records

The snapshot pattern is not a novel demand invented for AI. It is how record-keeping regulation already works in domains where decisions get disputed. When the SEC amended its electronic recordkeeping rules for broker-dealers in 2022, it allowed an audit-trail alternative to write-once storage, on the condition that the system can recreate an original record if it is later modified or deleted, with a complete time-stamped trail of every change. The regulatory instinct is exactly the snapshot instinct: the current state of a record is not an acceptable substitute for the state that applied at the time.

AI-specific frameworks point the same direction. Article 12 of the EU AI Act requires high-risk AI systems to be designed to automatically record logs over their lifetime, at a level of traceability sufficient to identify risk and support post-market monitoring, and traceability of a decision is hollow if the rules it was measured against cannot be established. The NIST AI Risk Management Framework treats traceability and documentation across the AI lifecycle as core to accountability. None of these names "policy snapshot" as a required artifact, and none prescribes a format. What they converge on is the expectation a snapshot exists to meet: that the organization can show, later, the basis on which an automated decision was made.

Where snapshots pay off in the evidence workflow

A policy snapshot is not only a defensive artifact for disputes. It does active work in the rest of the evidence pipeline.

It makes outcome verification precise. Verifying an action against a system of record requires an expected outcome, and the expected outcome comes from the decision and the policy that supported it. If the policy that generated the expectation is snapshotted, the expectation can be derived and audited independently of the agent that reported it. If it is not, the expected outcome is just another agent self-report.

It makes human review tractable. A reviewer handed the decision-time rules alongside the decision can judge the case in minutes. A reviewer forced to reconstruct which of four policy versions applied, from deployment timestamps and merge history, spends an hour per case or, more realistically, stops reconstructing and starts approving by default.

And it separates two failure modes that demand different responses. When a batch of agent decisions goes wrong under a correctly applied policy, the policy needs fixing. When the policy was right and the agent deviated from it, the agent needs fixing. Without snapshots, both look identical in retrospect: a pile of bad outcomes and a current policy document that condemns them. With snapshots, the two are distinguishable per action, which is what makes the fix targeted instead of speculative.

How Pruvz treats the policy snapshot

Pruvz is a business evidence layer for production AI agents, and the policy snapshot is a structural part of every evidence packet. When a consequential action is recorded, the packet embeds the policy that was in force at decision time: the policy identity, the exact version, the rules that applied, the inputs the evaluation saw, and the explainable result of every rule. The snapshot is captured once and read back from stored state, never re-evaluated on read, so a policy change tomorrow cannot rewrite what the record shows about today. The expected outcome that drives verification is derived on the server from the decision and that snapshot, and is never accepted from the agent. The division of labor is the point: the policy snapshot proves what should have happened, system-of-record verification proves what actually happened, and the evidence packet binds the two to one specific agent action. You can inspect a real example, field by field, in a published evidence packet from the product demo.

Pruvz is inviting founding design partners to shape the evidence layer around real production agent workflows. If your agents make policy-bound decisions today (refunds, claims, account changes, approvals) and you could not say with confidence which policy version any given action followed, that is exactly the gap a design-partner conversation is built to map. For the wider context of what a complete record contains, start with what business evidence for AI agents is.

This article is general technical and governance information, not legal advice. Your obligations depend on your jurisdiction, industry, and specific use case.

Frequently asked questions

What is a policy snapshot for AI agents?

A policy snapshot is a preserved, immutable copy of the rules, limits, and terms that were in force at the moment an AI agent made a specific decision, stored as part of that action's record. It typically includes the policy's identity, the exact version or revision, the rule content or a hash into immutable storage, the inputs the policy evaluation saw, and the result of each rule. Its defining property is that it is captured once at decision time and read back from stored state afterward, so later policy changes cannot alter what the record shows about the decision.

Why can't a reviewer just check the current policy?

Because the current policy answers a different question than the one a dispute raises. A dispute asks whether the action complied with the rules in force when the agent decided, and policies change between decision and review. Comparing an old decision against the current policy fails in both directions: a decision that was correct under the rules that applied can look like a violation under newer, stricter rules, and a decision that broke the applicable rules can look acceptable under newer, looser ones. Either error produces a confident review of the wrong question.

Is keeping policies in version control enough?

No. A version control history proves which policy versions existed and when they were authored, but not which version a particular agent actually evaluated for a particular action. Runtimes load policy on schedules, cache it, and receive it through distribution pipelines with lag, so the version merged in the repository and the version active in the deciding process can differ at any given moment. A policy snapshot closes that gap by recording what the deciding process actually held at decision time, bound to the individual action record.

What should a policy snapshot contain?

Seven elements make a snapshot reviewable months later: the policy's identity, the exact version or revision identifier, the rule content itself (by value, or by hash into storage that cannot be rewritten), the inputs the evaluation saw about the case, the per-rule results so the decision is explainable rather than a bare pass, the capture time, and a tamper-evident binding to the specific action record. The inputs and per-rule results are the elements teams most often skip, and without them a reviewer must re-derive the evaluation by hand.

Do prompts and retrieved documents count as policy?

Often, yes. If a system prompt instructs an agent that refunds over a threshold require escalation, that instruction functions as policy even though it lives outside any policy engine, and prompts change frequently and informally. The same applies to help center articles, macros, and terms pages an agent retrieves at decision time. A practical scoping test: any text that, had it read differently, would have changed the agent's decision is part of the policy surface for that action and belongs in the decision-time record.

Do regulations require policy snapshots?

Not by that name, but the pattern matches how record-keeping regulation already works. The SEC's 2022 amendments to its electronic recordkeeping rules for broker-dealers allow an audit-trail alternative to write-once storage only if the system can recreate an original record after modification or deletion, with a complete time-stamped trail. Article 12 of the EU AI Act requires high-risk AI systems to automatically record logs over their lifetime for traceability, and the NIST AI Risk Management Framework treats documentation and traceability as core to accountability. Exact obligations depend on jurisdiction, industry, and system classification.