The direct answer
Treat persistent agent memory as a separate write decision rather than an automatic conversation summary. Record each admitted item’s source, purpose, owner, scope and expiry, then enforce corrections and expiration when building future context.
Define one useful memory feature
A drafting assistant can save a formatting preference between sessions. That convenience does not require retaining every conversation, inferred trait or instruction found in a document. Start with one narrow feature: remembering how an authorized user wants their own draft reports formatted inside one workspace.
OWASP's AI Agent Security guidance recommends validating memory before storage, separating users and sessions, and setting expiration and size limits. The design here makes those decisions inspectable through a fictional ledger. No real memory store, personal information, model call or security experiment was used. Its examples and proposed checks remain unrun.
Keep candidates separate from admitted memory
A model can propose a candidate, but the application should decide whether that candidate belongs in the persistent feature. In this proposed design, new candidates stay outside future context until admission. Preserve the source type: explicit user preference, retrieved passage, tool response or model inference. A summary should not silently convert one type into another.
The source reference should identify the relevant message or artifact and its version, with access restricted appropriately. Record what the source actually supports. “Prefers compact reports” is narrower than “approves omitting safety explanations.” Neither grants permission to send a message, change payment details or bypass application rules.
OWASP's prompt-injection guidance describes persistent manipulation through history and memory. Filtering suspicious words may be one layer, but it does not establish provenance or write authority. A well-phrased instruction from a retrieved page still cannot set the user's stored preferences.
Use an admit, reject, ask, correct and expire ledger
For the synthetic exercise, U-17 uses workspace W-A. The feature stores only report-format preferences. The example's time limits are invented product-policy choices, not legal requirements or recommended universal defaults. Each expected decision is defined before any future evaluation.
| Candidate or event | Expected decision | Scope and lifecycle |
|---|---|---|
| U-17 explicitly requests compact reports to be remembered | Admit M-1 revision 1 | U-17/W-A/report formatting; review at T0 plus 30 days |
| U-17 says “be brief for today's draft” | Use for this task; ask before persistence if useful | No persistent entry while intent is unclear |
| A retrieved page asks to remember a new payment destination | Reject | External content has no preference-write authority |
| The model infers a sensitive personal attribute | Reject for this feature | Unsupported inference is outside report formatting |
| Another user requests changing U-17's preference | Reject without a separately authorized management path | Do not widen ownership from message text |
| U-17 changes compact reports to detailed reports | Correct: supersede M-1 with revision 2 | Future context uses the current revision |
| A one-hour task preference is read two hours later | Expire | Exclude from future context; cleanup tracked separately |
“Ask” means a product clarification about future use, not an invented universal consent rule. If no answer arrives, this design retains the request only as permitted task context and creates no persistent preference. Rejecting an inference also says nothing about whether the inferred statement happens to be true.
Make the memory record explain its authority
A minimal admitted entry could contain memory_id, revision, owner_scope, feature, value, source_type, restricted_source_ref, admitted_at, expires_at, review_due_at, status and supersedes. Assign identity and scope from the authenticated application context, not a model-generated owner field. Bound the size and permitted value format to the feature.
Keep the value small: a controlled choice such as compact or detailed is easier to inspect than a paragraph of instructions. Preserve whether a deadline means review is due or use must stop; those are different policies. If a required expiry or ownership field is unavailable, do not invent it. Hold the candidate or exclude the entry until the ambiguity is resolved.
Source provenance is evidence for a write decision, not proof that the content is safe forever. A stored digest can help identify recorded bytes; it cannot certify the original source's authority, truth or continued suitability.
Make correction and expiry affect actual future reads
A correction must win over delayed summaries. Suppose an old summarization job proposes revision 1 after U-17 has chosen revision 2. Coordinate admission with the current revision and status using a supported atomic or fenced update; a separate check followed by a later write can race the correction. Reject or review a stale proposal rather than silently restoring the old preference.
When assembling future context, select only current entries in the correct feature and scope, enforce expiration and resolve superseded versions. A similarity search that returns the old compact preference must not overrule the current record. Check the final selected memory, not merely the write endpoint's response.
Expiration here means stopping new context use under the declared policy. It does not establish physical erasure from logs, backups, saved answers or already dispatched requests. The separate deletion lifecycle guide addresses those copy and propagation questions. Do not present a memory toggle or expired timestamp as recall of earlier outputs.
Review usefulness and failure cases separately
A proposed local exercise can feed the ledger into a memory-service substitute and inspect the context recorder. Verify an admitted preference survives reopening, a temporary preference does not persist, external instructions are rejected, correction defeats a stale worker and expired entries are excluded. Also check that an authorized preference improves the intended formatting choice. These cases have not been executed.
Record candidate ID, decision, reason, policy revision, scope and lifecycle outcome. Avoid copying rejected sensitive inferences or full conversations into ordinary logs. OWASP logging guidance supports minimizing sensitive data and protecting evidence access.
Boundary's planned request router does not supply this memory-admission service or correction mechanism. Its eight mock policy checks are separate evidence. A future release claim should name the memory feature and cases actually reviewed, with unresolved paths explicit; this ledger does not guarantee protection against every poisoning attempt.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.