A payment policy changes from one reviewer to two. An agent retrieves a summary written before the change. The summary may describe the old policy accurately. Whether it can be used in a payment decision today depends on which policy is authorized and in effect for this customer and this action.
Persistent memory turns that distinction into an engineering problem. Stored information can support historical explanation, planning or execution, and each purpose needs a rule for which records apply. This post reviews recent research, reports seven small checks against a published memory guard, and proposes a worksheet for policy applicability. This post is part of a three-part research series on agent authority, published 26 October 2026: stop evidence, policies in agent memory and agent control standards.
Recent research gives the problem a concrete form
In Revoked but Still Authoritative, a September 2026 preprint, Yi Ting Shen, Kentaroh Toyoda and Alex Leung study how revoked information resurfaces in agent-memory workflows. The paper covers several memory systems and insertion methods, with experiments on write-back, shared stores and tool use. Read the paper.
Configuration matters to the results. The paper separates Graphiti’s default retrieval from a mem0 condition that overrides mem0’s shipped expiry filter. Other systems behave differently depending on how a policy update enters memory and whether revocation status reaches the caller. Read the study’s results with those conditions attached.
The authors also publish a retrieval guard. It uses available revocation metadata and heuristic conflict detection to decide which records to withhold. We inspected the implementation and ran it locally at a pinned commit. Its built-in self-check passed. We then gave it seven small synthetic cases designed to show where policy selection needs more context. Published guard.
What the seven checks showed
The first three cases match the guard’s documented behaviour. It withheld an explicitly revoked record. It preferred the newer of two conflicting timestamped records. When neither record carried a usable timestamp, it kept both and reported an unresolved conflict.
The other four cases add context a policy decision needs and this guard does not resolve:
| Synthetic task | Observed selection | Context the caller needs |
|---|---|---|
| Two policies apply to different customers | The newer policy remains in kept | Customer scope, before comparing replacements |
| A newer unapproved note conflicts with an approved policy | The newer note remains in kept | Which source can authorize a policy change |
| A newer record takes effect in 2099 | The future policy remains in kept | The effective interval at the decision date |
| An audit question needs the earlier policy | The current policy remains in kept; the earlier one is in withheld | Historical retrieval suited to the question |
How to read these results
These are deterministic observations of one filtering function. Customer, authority and effective-date fields go beyond its documented selection rules, and it takes no parameter for the purpose of the query. The cases describe responsibilities for the application that integrates the guard. They do not show a vulnerability in the guard or in memory systems generally, and seven chosen cases say nothing about frequency. No model, memory service or payment tool ran.
The historical case needs care. The guard keeps the withheld record in its output, so an application can still read it. The integration decision is whether an audit question should use the same filtered context as a request to execute the current policy.
Make applicability explicit
The design we propose starts from the task. A question about last month’s approval may need a superseded policy. A request to release a payment needs the policy in effect for that action now. Keeping the purpose explicit lets a system keep useful history and still select the right context for execution.
The next step is to resolve scope and authority. A policy record should identify the customer or tenant, the governed action, the issuer, the approval status, the effective interval and what it replaces. A newer timestamp helps order records once those relationships are known. It cannot supply an approval that never happened.
Last, the component that can cause a consequential action should evaluate the authorization that applies. A retrieved summary can carry a policy identifier and explain a proposed action. The execution decision should be tied to an authoritative policy version and recorded with its outcome. This is a design recommendation; we have not benchmarked it.
- 1. Purpose: historical explanation, planning or execution.
- 2. Scope: customer or tenant, resource and governed action.
- 3. Authority and time: issuer, approval record, effective start and end, supersession.
- 4. Selection: the applicable policy and any approved exception.
- 5. Decision: evaluate the proposed action against the authoritative version and keep the reference.
A worksheet for policy applicability
Related research covers neighbouring problems. MINJA studies how interaction can contaminate an agent’s memory, and VersionRAG examines questions over changing document versions. MINJA, VersionRAG.
For a policy owner, a useful record answers four questions: where the policy came from, who approved it, when and where it applies, and which decisions relied on it. The policy applicability worksheet turns those questions into fields a team can check.
| Decision field | What to record |
|---|---|
| Task purpose | Historical explanation, planning or execution; the decision time and any historical date requested |
| Scope | Customer or tenant, resource and governed action |
| Policy | Identifier and version |
| Authority | Issuing authority and approval record |
| Effect | Effective start and end; withdrawal or supersession state; explicit replacement relationship |
| Exceptions | Approved exception, its scope and expiry |
| Sources | Source documents and the derived summaries that reference them |
| Conflicts | Conflicting evidence and the responsible policy owner |
| Execution | The authoritative check and its recorded outcome |
Where KLA evaluates policy
In KLA, a governed action is evaluated by the KLA Policy Engine at the point of execution, with one of four outcomes: allow, warn, require_approval or block. When evaluation fails, the engine returns its fail-closed decision, require_approval by default, and policy-pack lint rejects a policy whose default decision is fail-open. An agent’s remembered policy summary can inform its proposal. The decision comes from the published policy version.
The checks in this post ran against the published guard only. They contain no KLA result.
Frequently Asked Questions
Why do AI agents use outdated policies from memory?
A memory store can hold a summary written before a policy changed. Retrieval may rank it highly, and a newer record may concern a different customer, lack approval or not yet be in effect. Unless the application resolves scope, authority and effective dates, the agent can act on a policy that no longer applies.
Does a newer timestamp mean a policy record is the current one?
No. A timestamp orders records once you know they cover the same scope and that the newer one was approved and is in effect. In our checks, a published guard kept a newer unapproved note and a policy dated 2099, because its contract does not cover approval or effective intervals.
Should an agent delete superseded policies from memory?
Keep them for history and route them by purpose. An audit question may need the earlier policy; an execution request needs the one in effect. The guard we tested keeps withheld records in its output for that reason.
Where should the final policy check happen?
At the component that can cause the consequential action, against an authoritative policy version, with the version and outcome recorded. Memory can explain a proposal. The policy check decides whether the action runs.
Key Takeaways
Remembered policy is useful context and unreliable authority. Decide the purpose of each retrieval, resolve scope, approval and effective dates before trusting recency, and make the execution check against the authoritative version. Use the policy applicability worksheet to record those decisions.
Sources were checked on 26 October 2026. All seven cases are synthetic, ran against one published function, and measure nothing about deployed systems.